What did you do to develop good code designing practices

Question

I've been programming c++ for four years and java for two, I feel that I have a strong grasp of the languages them selves, although I'm no wizard in either. It seems that once I hit the 75% completion mark my code seems to be a god awful ball of spaghetti mess, sometimes to the point of unreadability. What have you done to produce good readable code?

Answer 1

unit tests!!! if you have unit tests, it seems to force modularity, because to be able to write (good) unit test, you need to have small components that are easy to test, otherwise, those unit tests never get written =)

Answer 2

Read Steve McConnell's brilliant book Code Complete. If I had to recommend just one book every software developer should have read, that would be it.

Answer 3

Read Code Complete. This is the ultimate reference of good coding practices.

Also experience in maintaining your own messy code will teach you ;)

Answer 4

The algo I followed is pretty simple:

1. Study the code you consider to be good
2. Decide what aspects of the code you study are better then in your code
3. Improve your code untill you are happy with the way it reads

Later I've read THE book Refactoring: Improving the Design of Existing Code (Amason link) . It contains concrete advices of do-s and dont-s for clean and pretty code with Java & Python examples.

Answer 5

Learn to recognize the developing spaghetti mess early and be merciless in refactoring when you notice a bad design decision starting to cause problems.

You should always be paying attention to stuff you have already written and be willing to change things when you realize that it could have been done a better way. The key, however, is being able to recognize these things early so that you spend minimal time fixing them.

Answer 6

Found a design mechanism that worked for me. Tends to be something like edges in. i.e. I "know" or think I do, what the lower layers need to do, and "know" what the top interface is.
From that you can generate some kind of working code fairly early, and it is easier to keep it modular.

The correct answer should probably be to design the whole thing, but in my experience you don't often have the chance / ability to do that, so do what you can - then make it better.

Writing Solid Code and Code Complete are great reference books for code quality, but good design is much harder to achieve as we all think our programming problems are unique.

Answer 7

Fail at it a few times. When you write code, look back on it a few months later and figure out what works well and what doesn't. Your failures are you greatest strengths, because you can use them to improve your future efforts.

Answer 8

To rephrase @jxie: Test-Driven Development both requires and creates decoupled code.

The Refactoring book had a bigger impact on my ideas about writing good code, but that may just be because it hit me at the right time.

Getting your code clean and clear matters. A lot. Good for you thinking about it.

Answer 9

Spaghetti code is easily avoid by Refactoring. Refactoring is easily done when you have unit tests.Test-Driven Development forces you to write the unit tests before you write the code. TDD will show you if your code is easy to use and if the design is intuitive.

So to answer your question, I will say you need to add TDD and Refactoring to your toolbox.

Answer 10

Always read other peoples code. This helps in many ways to see how to improve your design practices.

I also downloaded StyleCop. Which helps greatly!!!

Answer 11

In terms of readability, there are a lot of small habits that I've formed that help me keep my code "visible", in other words, legible to the point where I can look at a single screen and know what the blocks of code on that screen do.

Use lots of white-space. I put spaces around everything. Nothing bothers me more than reading code where some "clever" programmer has packed all the operators in an equation together with no whitespace. Who does he think he's helping? The compiler?

Keep methods short. If a method is approaching a screen-full of text, break it out into smaller methods.

Refactor constantly. Goes without saying, and keeping your methods short is part of this.

Throw code away. I usually write everything at least twice. I'll code an entire solution, knowing full well that it's poorly structured. Once it's finished, I'll throw the whole thing away, and start over, but now with a lot more knowledge about the problem, as well as pitfalls to expect.

Answer 12

I am a strong proponent of the learn by doing mantra. The more you code, the more you work on other developer's code, and the more you read about development the better your code will be. Tutorials often use bad practices and bad form, because they are trying to teach general concepts. Real, production level code is what you want to work on, dive into, and breathe. Not every job you have will have perfect code, but the more you see and learn from that code the better a developer you will be. Be passionate about improving your work, and act on that. Read over code you've never seen before, check out articles on security, frameworks, and runtime. Apply that knowledge, and soon it will all trickle down into your work.

Answer 13

Since the topic of refactoring has cropped up, I'd suggest to use an IDE that has good refactoring tools built such as Eclipse.

Changing variable names, class names, factoring classes out are just a few of the refactoring tools that are just very simple to do. For me, the ability to refactor alone made me abandon the text editor I was using (for all but the simplest of projects).

Since you said that you use Java and C++, Eclipse can be a good choice as it supports both languages. (Through the Java development tools and the C/C++ Development Tooling, respectively.)

If your IDE already has refactoring features, use them! It could help you reorganize your code to make it less of a mess.

Answer 14

1. Know your audience (other programmers, developers, architects, project managers)
2. Do code reviews with others.
3. Look to the domain (business and customer) for modeling classes/objects that make sense to them.
4. Read Code Complete (although I am only 9 chapters into it).

Not necessarily in that order of priority.

Answer 15

I remembered what I didn't like about other people's code, those things that made it sloppy. But mostly, what keeps me having good coding practices is reading my old unreadable code and wondering what the heck I was thinking. So now when I code I want to make it so I know exactly what I was doing when I read the code again.

Answer 16

Refactoring Triage

Recently, I participated in refactoring a rather large project in a relativly short period of time. This required that we perform a sort of refactoring triage. The goals we chose for impoving maintainability and readability were as follows:

Remove Unused Code

Any code which is not called, should not be part of the project.

This includes commented out code, or code that does not have a use case.

Cleanup of Comments

Comments in the body of the code should be a concise as possible, and only exist where the code is not understandable...

But if the code is not understandable, you should probably rewrite it instead.

External interfaces for classes, functions and structs should be commented, but the comments should be about how to use the interface, not how the implimentation works.

Flatten Inheritance Hierarchies

Use inheritance to express "is a" relationships.

Inheritance is good for polymorphism (like we use Interface for).

Not good for code reuse, composition is better for those circumstances.

Follow Consistent Coding Standards

Naming Conventions

File Structure

Avoid "magic numbers", instead use named constants

Answer 17

Read tons of code and tons of books. For example browse www.koders.com