4

Writing clean, elegant code is what makes coding a pleasure for me. I'm always looking for more ways to do so. Here are some of my strategies/tactics:

  • Keep large code blocks in smaller chunks of routines/methods/classes

  • Be sure every routine has one point of exit. Exit loops with logic at the top of the loop, not with breaks or some type of "exit loop" keyword.

  • Avoid globals

  • If you just performed a copy/paste with your code, it is time to create a routine/class/library.

...and one I've been toying with lately:

  • Try to replace if/branching/select cases with different method signatures (polymorphism) Clean Code Talks on YouTube
Joel Coehoorn
  • 399,467
  • 113
  • 570
  • 794
DeveloperMCT
  • 335
  • 2
  • 4
  • 14

9 Answers9

16

Clean Code by Robert C. Martin

alt text

Glorfindel
  • 21,988
  • 13
  • 81
  • 109
Chuck Conway
  • 16,287
  • 11
  • 58
  • 101
5

If you haven't read Code Complete, I strongly recommend you stop reading Stack Overflow for a few days (or however long it takes you) and read that 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

mandaleeka
  • 6,577
  • 1
  • 27
  • 34
3

"one, two, many".

A remote wild population in some remote angle of the planet has no words in his language to count beyond two. After two, there's a word for "many". My previous boss preached this phrase to keep low the number of arguments in a 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 should refactor. Sooner or later the two (or more) places will be desynchronized.

"Keep It Simple, Stupid (KISS)"

Don't overdesign.

Stefano Borini
  • 138,652
  • 96
  • 297
  • 431
  • 1
    I originally heard "one, two, infinity" and its variations as an explanation of when to write a tool to automate a task. – Steve S May 02 '09 at 03:43
3

Don't procrastinate. Ever. When you think of a way to improve a section of code, go and do it right then, no matter how hard it may be, or how long it might take. Always look for potential improvements and never take the easy way out.

Now, this is not the most efficient or profitable way of developing code, which is why professional codebases are rarely examples of beauty. But that wasn't your question.

tsimon
  • 8,362
  • 2
  • 30
  • 41
2

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

"In Programming there are only 3 numbers: 0, 1, and infinity."

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

Mike Lewis
  • 1,292
  • 7
  • 8
1

Yup, those are good ones.

The best one, I think, is to assume that the first version isn't the final one. plan to rewrite and refactor. Look at smallish chunks, and think how they could be done more elegantly.

Also, read code, especially known good code.

Charlie Martin
  • 110,348
  • 25
  • 193
  • 263
1

-Keep large code blocks in smaller chunks of routines/methods/classes

What I like to do is create one main function at first so I don't have to create tons of mini-functions from the get-go which hampers my train of thought, and then later refactor it into smaller functions. Refactoring is great.

Be sure every routine has one point of exit. Exit loops with logic at the top of the loop, not with breaks or some type of "exit loop" keyword.

This is not necessarily cleaner. It only makes it easier to prove a function's correctness. See Should a function have only one return statement? for more details.

Avoid globals

Sometimes globals are okay. Many times people use a singleton just to avoid using a "global" which is actually a global in disguise with more overhead.

Community
  • 1
  • 1
Unknown
  • 45,913
  • 27
  • 138
  • 182
0

While perhaps not exactly the type of answer you are looking for I'd say Component-based design tends to lend itself to elegant code by way of elegant architecture. Thinking about how to segregate code will apply structure and order to an otherwise chaotic process (at times). Code elegance can either be fretted about up front, before implementation (you better be thorough), or sought after initial integration through refactoring and simplifying. If you go with a Component-based model then refactoring integral pieces of your application becomes a much more manageable task - so long as the input and output remains unchanged through the process of beautification/simplification. Focusing on overall application structure has, for me, become a crux for elegant code. It's difficult to achieve the latter without the former unless your application has a small scope.

The bottom line is code is a malleable and ever-changing process. Elegance is only such at various points in time because something can start elegant and after a few iterations become kludge. After that occurs it's refactored into elegance again and so on which is why supporting that idea through sound architecture will make it easier to keep your code as elegant as it can without breaking unrelated items.

methodin
  • 6,717
  • 1
  • 25
  • 27
0

Often times, clean code is associated with short functions or better indentation. So do not fall into that trap. Spend considerable time in designing classes. There are good principles out there such as SOLID principles that will allow you to design and build good meaningful classes. Then comes the selecting appropriate design patterns to model the behavior of your classes. Of course always remember to follow the keep it simple principle. Finally, make sure there is sufficient code coverage for complex functions in your architeture. Following all these things can help you write clean code. Here is a good list of books that I recommend to my friends and colleagues.

Srikar Doddi
  • 15,499
  • 15
  • 65
  • 106