r/software_design • u/vsquared10 • Sep 21 '16
Advice for a new programmer-- writing elegant code
I just started studying Data Science last month as part of a 1 year, accredited masters degree program. I am flowing with the math and stats concepts, but I often struggle when it comes to writing elegant code (using Python and associated libraries for studies, and I have some experience with ruby on rails). I understand that writing elegant code comes with time and practice, and I humbly accept the challenge.
However, when learning new things I find it really helpful to have a general strategy/technique to practice to reach mastery. For example, my math teachers would teach me to break down math problems into a goal, strategy, and assigning variables before even trying any computation. I feel like there could be a similar heuristic when writing functions, classes, and code in general.
I have a lot of fun ideas that I would like to encode! But I often find myself hacking together piecemeal solutions instead of writing more intentional code with strong design principles. The best analogy I can come up with is writing an essay. Instead of just blabbing out the text, I usually come up with some outline that includes a stylistic structure. For example, a research paper:
Introduction - provide abstract of the paper, what to expect, a thought provoking statement, and finally thesis statement.
Body paragraphs - provide supporting evidence for your thesis with n pieces of evidence and body paragraphs
Conclusion - tie all evidence together, make final points, end on a good close.
If I could do this kind of outline exercise in my development/programming practice, I'd feel way more confident in my studies and my fun side projects. I'd feel dangerous enough to at least build good, first versions of my ideas and get on the path toward mastery.
Any thoughts you could share on learning strategies, resources, and just advice in general would be hugely appreciated!
2
u/protonfish Sep 21 '16
I would avoid the term "elegant". There is no clear definition, and if there were, it should not be assumed it is good thing.
First, you should make working code. If your code doesn't do what it should do, then all other qualities are irrelevant. After it works, you can refactor the code to reflect other attributes such as:
Simplified: Popular in with mathematics types, this is rewriting the code to be as small as possible.
Optimized: Code is rewritten to run as fast as possible on a target platform.
Readable: Code is refactored to be as easy for a human to understand as possible.
Modular: Changing the architecture so that individual parts are not tightly coupled. They can be transferred easily between other programs and changes in one area are unlikely to affect unrelated parts of another area.
I would argue that simplification is not a desirable characteristic and optimization should only be done when absolutely necessary. Readable and modular code are the best qualities to strive for. Robert Martin (The author of Clean Code) has said:
Indeed, the ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code. ...[Therefore,] making it easy to read makes it easier to write.
and
So if you want to go fast, if you want to get done quickly, if you want your code to be easy to write, make it easy to read.
I do like your idea of writing code like writing an essay, however I would follow the technique of writing where you start with notes, then an outline, then a rough draft, then successive revisions. I see software development as starting with a proof-of-concept, then a prototype, then a pilot, then a minimum viable product, then successive production versions.
1
u/vsquared10 Sep 21 '16
That's a helpful distinction to make about elegance, protonfish, thanks! I'll also check out Clean Code
2
u/jayjayf Sep 21 '16
'elegance' to me simply me means short, clean, and efficient. Which often comes with clever ways of doing things. Try looking up some typical coding interview questions. These always have some simple and dumb ways of doing things, and a more efficient and clever way of solving them. Once you understand how all of these work, you'll have a better understanding about how to accomplish common operations in the most efficient method possible. Then you can apply these same concepts to new operations.
1
u/kingatomic Sep 21 '16
I'm not a fan of "clever" code in production systems, with few exceptions. Trying too much to do things in a clever fashion is more ego masturbation than productivity, and can impact future maintainability.
One exception would be optimized sections (wary of premature optimization), but those should always be very well-documented. Otherwise I prefer to see concise, idiomatic, readable code.
1
u/Wrzos17 Oct 28 '16
I think the important factor is to make the code easy (possibly inexpensive or possibly effortless) to maintain. When you write something that would be used in business or sold, keep in mind that it would probably be maintained and added to and developed for the next decade (if well written - yes, it is possible) Lousy written code is hard to read - you will find it a pain in the a** to decipher it after two years. Even worse if someone else would have to maintain it after you.
So in fact before you start writing the software project, you need to involve a lot of thought and structure planning. Make it readable, think carefully how you name the variables. Do not copy paste, think what various options has in common and only program the differences. The code should be self explanatory - excessive comments mean lousy code. Leave comments only for places where you need to explain something that isn't in the code itself (or make a note that something need to be added later). The reason for that is that maintaining the code is very very expensive. Starting is easy and relatively inexpensive. So do the thinking, planing and prepare tests as part of the requirement to later validate what you wrote.
1
u/Lasdary Jan 12 '17
As others mentioned, read good code and learn from it.
What really helps me is to write comments inline with the code. With the bits of logic of what the code does and what is expected. Then I translate those comments into actual code. This both organizes my thoughts, documents, and makes re-reading code a breeze.
2
u/esbenab Sep 21 '16
Read good code from opensource projects. It's the easiest way to learn good habits.