Tips for creating clean, elegant code

Writing clean, elegant code is what makes coding enjoyable for me. I am always looking for more ways to do this. Here are some of my strategies / tactics:

  • Store large code blocks in small pieces of routines / methods / classes

  • Make sure that each program has one exit point. Exit the loop with the logic at the top of the loop, not with breaks or some type of keyword "exit loop".

  • Avoid global bindings

  • If you just did a copy / paste using your code, it's time to create a routine / class / library.

... and the one I've been playing with lately:

  • Try replacing if / branching / select cases with different method signatures (polymorphism) Pure code conversations on YouTube
+4
source share
9 answers

If you have not read “Code Complete,” I highly recommend that you stop reading “Stack Overflow” for a few days (or no matter how long it takes), and read it instead.

alt text http://ecx.images-amazon.com/images/I/51seLiYuURL._BO2,204,203,200_PIsitb-sticker-arrow-click,TopRight,35,-76_AA240_SH20_OU01_.jpg

+5
source

"one, two, many."

A remote wild population in some remote corner of the planet does not have words in its own language to count for two. After two words, there is the word "many." My previous boss preached this phrase to keep the number of arguments in the routine. I tend to agree with him.

"Don't Repeat Yourself (DRY)"

if you say the same thing in two places, then you have a problem and you must reorganize. Sooner or later, two (or more) places will be desynchronized.

"Keep it simple, stupid (KISS)"

Do not overestimate.

+3
source

Do not delay. Ever. When you think of a way to improve a section of code, go do it right, no matter how hard it is or how long it can take. Always look for potential improvements and never make an easy exit.

Now this is not the most effective or profitable way to develop code, so professional code bases are rarely examples of beauty. But that is not your question.

+3
source

In Comp Sci, I heard something that always stuck with me:

"There are only 3 numbers in programming: 0, 1 and infinity."

Practical realities, of course, force us to use other numbers. But I always feel that my code becomes less elegant if I use a number other than the three.

+2
source

Yup, these are good.

It is best, I think, to assume that the first version is not the last. plan to rewrite and refactor. Look at the little pieces and think about how they can be made more elegantly.

Also read the code, especially the famous good code.

+1
source

-Support large code blocks in small pieces of routines / methods / classes

I like to do one main function first, so I don’t need to create tons of mini-functions from the very beginning, which complicates my train of thought, and then reorganizes it into smaller functions. Refactoring is great.

Make sure that each program has one exit point. Exit the loop with the logic at the top of the loop, not with breaks or some type of keyword "exit loop".

It is not necessarily cleaner. This only simplifies the proof of the function. See If a function contains only one return statement? for more details.

Avoid global bindings

Sometimes globals are fine. Many times, people use singleton just to avoid using the “global,” which is actually globally hidden with lots of overhead.

+1
source

Often, clean code is associated with short functions or improved indentation. Therefore, do not fall into this trap. Spend considerable time developing classes. There are good principles, such as SOLID principles , that will allow you to create and create good meaningful classes. Then comes the selection of appropriate design patterns to model the behavior of your classes. Of course, always remember to follow the principle of "keep him alone." Finally, make sure your architecture has sufficient code coverage for complex functions. Following all these, you can write clean code. Here is a good list of books that I recommend to my friends and colleagues.

0
source

Although it may not be exactly the type of answer you are looking for, I would say that component design tends to succumb to elegant code through elegant architecture. Thinking about how to separate the code will apply structure and order to the chaotic process (sometimes). The elegance of the code can be upset before implementation (you better be careful), or looked after the initial integration through refactoring and simplification. If you go with a component-based model, then reorganizing the integral parts of your application becomes a much more manageable task - until the input and output are changed without changes in the process of improvement / simplification. Focusing on the overall structure of the application has become for me elegant code. It is difficult to achieve the latter without the first if your application does not have a small amount.

The bottom line is that code is a malleable and ever-changing process. Elegance exists only at different points in time, because something can begin to grace and after several iterations become a claude. After that, it is again converted into elegance, etc., Therefore, supporting this idea with the help of sound architecture will simplify your code as elegant as possible, without breaking unrelated elements.

0
source

All Articles