How do you know you're writing good code? [duplicate]

Question

I love programming. I've been messing around with code since I was a kid. I never went the professional route, but I have coded several in-house applications for various employers, including a project I got roped into where I built an internal transaction management/reporting system for a bank. I pick stuff up quickly, understand a lot of the concepts, and feel at ease with the entire process of coding.

That all being said, I feel like I never know if my programs are any good. Sure, they work - but is the code clean, tight, well-written stuff, or would another coder look at it and slap me in the head? I see some stuff on Stack Overflow that just blows my mind and makes my attempts at coding seem completely feeble. My employers have been happy with what I've done, but without peer review, I'm in the dark otherwise.

I've looked into peer code review, but a lot of stuff can't be posted because of NDAs or confidentiality issues. A lot of you professionals might have teammates to look at stuff over your shoulder or bounce ideas around with, but what about the independent and solo guys out there like me? How do you learn best practices and make sure your code is up to snuff?

Or does it not matter if it's "the best" as long as it runs as expected and provides a good user experience?

Answer 1

The biggest clue for me is:

When you have to go back and add/modify a feature, is it difficult? Do you constantly break existing functionality when making changes?

If the answer to the above is "yes" then you probably have a poor overall design.

It is (for me at least) a bit difficult to judge a design until it is required to respond to change (within reason of course; some code is just bad and you can tell right away, but even that comes with experience.)

Answer 2

This is certainly a pretty standard measure where I work.

Which door represents your code? Which door represents your team or your company? Why are we in that room? Is this just a normal code review or have we found a stream of horrible problems shortly after going live? Are we debugging in a panic, poring over code that we thought worked? Are customers leaving in droves and managers breathing down our necks...

(Robert C Martin, Clean Code - book that opens with above picture)

Answer 3

You know you are writing good code when:

• Things are clever, but not too clever
• Algorithms are optimal, both in speed as well as in readability
• Classes, variables and functions are well named and make sense without having to think too much
• You come back to it after a weekend off, and you can jump straight in
• Things that will be reused are reusable
• Unit tests are easy to write

Answer 4

Although you said you don't have other coders around to do this, I'll include this for the sake of others.

The code quality test: Have another programmer who has never seen the code read it an explain what each module does to you while you look over their shoulder. The stronger your urge to jump in and explain something the worse the code likely is. If you can calmly sit there with your mouth shut and they don't need to ask a lot of questions, you are probably good.

For your benefit, here are some general guidelines for when you don't have a peer handy. They are not absolutes, just "smells".

Good signs

• Methods tend to be very short that ideally perform a single task.
• You have enough information to call methods WITHOUT looking at the body of them.
• Unit tests are easy to write.

Bad signs

• Long methods made up of 2-3 sub-tasks that are not broken out into other methods.
• Methods share data through some means other than their interface.
• If you change the implementation of one method (but not the interface) you need to change the implementation of other methods.
• Lots of comments, especially long winded comments.
• You have code that never runs in your application to provide "future flexibility"
• Large try/catch blocks
• You are having a hard time coming up with good method names or they contain the words "OR" and "AND" (e.g. GetInvoiceOrCustomer)
• Identical or nearly identical blocks of code.

Here is a longer list of code smells that should also be helpful.

Answer 5

For me personally, I think it's when I forget about the code. In other words:

• Bugs rarely occur
• When they do occur, other people resolve them without asking me anything
• Even more important, no one ever asks me anything regarding my code
• People don't have a high rate of WTF/min when reading it
• A lot of new classes in the system start to use my class (high fan-in, as Steve McConnell would call it)
• The code is easy to modify and/or refactor when/if needed, without cursing me (even if it's me - cursing myself!)
• I also love it when I guess just the right amount of abstraction which seems to suit everyone on the team

It's a nice feeling when you open a file you've written a year ago and see all the nice additions to a class, but very few modifications, and - very high fan-in! :)

Of course, these are the things that make me feel like I'm writing good code, but in reality, it's really hard to know. My guess is, if people start making fun of your code more than they're making fun of you, it's time to worry.

Answer 6

I have three golden rules:

1. If I feel compelled to copy/paste blocks of code I'm doing something wrong
2. If I can't take the whole code in my head I'm doing something wrong
3. If someone jumps in and gets lost in my code I'm doing something wrong

Those rules has guided me to do some real architectural improvements, ending up with small, clean and maintainable classes/methods.

Answer 7

This is an excellent question, and I applaud you for even asking.

First, it's good to get your mind blown every once and a while. Keeps you humble, keeps you realizing that you don't know everything, that there are people out there better at you than this, and gives you something better to strive for.

Now, how do you know when you're writing good code?

• When your classes each serve a single, very clearly defined purpose, separated from other classes with other clearly defined purposes.
• When your methods are short - ideally under 50 lines and certainly under 100 - and their names clearly define what they do exactly. A method should not do anything but what it's name implies. If you're going over 100 lines, or tabbed in very far, you can probably pull something out into it's own function.
• When your code provides one way to do something - when it does not provide the option to zig or zag, but instead provides a single linear path for each possible course of action the user may send it down.
• When you've done everything you reasonably can to reduce coupling between classes; so that if Class A depends on Class B, and Class B is removed and Class C is put in it's place, little to no changes have to be made to Class A. Class A should be as blind as possible to what's going on in the outside world.
• When your class, method, and variable names can be read and immediately understood by anyone that comes across the code - there's no need for 'pktSize' when 'packetSize' reads much more easliy.

As others have said, essentially, if you're doing Object-Oriented Programming, and when the time comes to change something you find it like trying to untangle and rewind a ball of yarn, the code isn't following good Object-Oriented principles.

I highly recommend the book "Clean Code", if you're interested in digging a little further into this. It's a good read for novices and experts alike.

Answer 8

I'd say my main points would be:

• Readability (for you and anyone else who has look into your code)
• Maintainability (easy to modify)
• Simplicity (not complicating things when there's no need for that)
• Efficiency (of course your code should execute fast)
• Clarity (if your code is self-explanatory, there's no need for comments most of the time, name your methods/properties etc. sensibly, break the long code down, never copy & paste a block of code)

I'm not putting Design in this list as I believe a good code can be written without sticking to a design pattern as long as it's consistent within your project.

Good MSDN article on this topic: What Makes Good Code Good?

Answer 9

Look around for a good open source project in your favorite language and see what they do.

For example, sendmail is someplace to look to see if you write spaghetti code. It's not sendmail's fault really; it's just 20 years old so it has a lot of cruft in it. So if your code looks like sendmail code, you're probably on the wrong track.

I have not looked at Postfix lately myself, though, and it is probably very well designed. So if your stuff looks more like postfix you're on the right track.

When I started programming as a kid there was no Internet and you had nothing to compare to. But now with a bazillion lines of code available for viewing for comparison, you should start to get an idea if you're doing it right or not.

And just because the Linux kernel is the Linux kernel doesn't mean it's well written. Keep that in mind.

Answer 10

This has been my experience since shifting from the college world of programming to the industry over the last five months:

• Ease of use is so important that we pay people just to design user Interfaces. Coders often suck at UI design.
• You find that that getting it to work isn't enough
• Optimizations become more critical in real-world scenarios.
• There are a thousand ways to approach a problem. However, often times the approach does not account for slightly less well-known factors that could adversely affect the performance of your approach such as database authentication, transactions, file I/O, reflection, just to name a random few.
• Maintainability is a very important aspect of coding. Just because your code is super optimized and super dense ... doesn't mean that it is sexy. Sometimes it is simply labeled as "Hero coding".
• Design skills are learned, not inherent. I'm sure there are a few brain children out there, but generally speaking, solid design with respect to real-world problems, is wrought through time, investigation, and most importantly, the imparting of knowledge from your superiors =P
• Documentation is not an convenience, it is a necessity.
• The same thing goes for unit testing (this varies from company to company admittedly)

I would suggest that you take an opportunity with an open source project. You will get a chance to see how much you really know if you work along side other programmers bottom line. An open source project is probably the best way to find out based on your background.

Answer 11

When you can read it like prose.

Answer 12

From a code and design perspective, I like what others have already said about maintainability.

In addition, I also look at stability. Look at the production support statistics. If you are getting a high instance of support correspondence for things that seem like fundamental functionality but are finding that many people are unable to understand how to use the software or are finding it does not meet their needs, then there's something wrong.

Of course, there are some users that are truly clueless, but if over time you're still getting reports of breakage, confusion, or significant feature change requests, then this is an indication that one or all of the following apply:

• The requirements were broken
• The code is broken
• The application is not intuitive
• The developer did not understand the user need
• Somebody pushed for delivery date over quality
• Somebody didn't test well or know what to test for

Answer 13

Read good code and figure out why it's good. Read bad code and figure out why it's bad. Read mediocre code and figure out which parts are good, which are bad, and which are ok. Read your own code and do the same. Pick up a couple of (well-regarded) textbooks specifically for the purpose of looking at the examples and understanding why they wrote them the way they did. Mostly, read code until you can tell the difference between bad and good, and can do your own "Wtf?" tests.

You can't know whether you're writing good code until you can recognize good code in general. Just because something's over your head doesn't mean it's well-written ...

("Read other people's code" has popped up in a couple of comments on this thread, but I thought it deserved its own post)

Answer 14

Ask someone else to take over your job for one day and check how stressed out he or she is at the end of the day ;-)

I'm bad at documenting and cleaning up stuff - so that's how I check it.

Answer 15

That all being said, I feel like I never know if my programs are any good. Sure, they work - but is the code clean, tight, well-written stuff, or would another coder look at it and slap me in the head?

Have you considered asking another coder what they think of your code?

Some places uses "peer review" where code must be acceptable to another coder before it is accepted to the code repository.

Answer 16

IMHO, there's no "good code" per se, but there's "good piece of software".

When we are working on something, there are many constraint on our work, which many times would make us producing the code that falls out of "good code" standard of other fellow programmers.

Some might say "good code" is the code that easy to maintain. The counterargument for this statement for me is, how easy? Do we need to put like 200% effort to the piece of code to make it so easy to maintain for the sake of "good code" standard, even we know we won't need to maintain it that much? I'm sorry but I don't think so.

In fact, I'm the one who really promote "good code" in my team that no one really cares for it. Every time I look at their codes, I never found that they write any perfect code. However, I must accept that they really got the job done, and also be able to maintain it adequately for our company needs. Of course the application is sometimes buggy, but we just made it in time, making our customers and users happy and securing our company in the position far ahead of our competitors.

So, I would say that "good code" is the code that produce what you need. You just have to think of what you really need, then use that to evaluate your code.

Answer 17

Good code is subjective to the person. A professional coder that has read lots of books and been to seminars and used different coding techniques would probably tear your code to shreds... However, I have found that code is really indicative of where the coders level of experience is. To me it reads like a history book or an auto-biography. It is what the coder knew at the time or what tools he/she was limited to.

Ask yourself this... Why does Microsoft take 3 versions of software to get something right? Because they are constantly fixing the mistakes they made in the previous versions. I know that my code always gets better and better after a revision. Sure there will be people here that say, I write code perfect the first time. If you believe that then I have some swamp land to sell you...

As you understand the concepts things get easier. For me, the beginning of learning something new is "can I get it to work?", then the next step is "I wonder if I can do it this way...", then usually when I've nailed it I ask "how can I make it faster"...

If you want to be a programmer then you have to dive into it and just do it. It takes a lot of work and to be honest it is like a piece of art that never can be finished. However, if you want to be just a casual hobbyist then if it works then don't worry about it. You have to adapt to your surroundings. If you don't have a way to do code reviews then ignorance is bliss =)

But no matter what... Everyone is going to have their own opinion. Sure there are right ways and wrong ways of doing things... But mostly I have found that there mostly better ways of doing things than just wrong ways...

Answer 18

For a particular piece of code:

If it works and is maintainable (pick your good practices), it is good code.

For you as a developer over time:

Good is a relative and dynamic term, to the language domain, problem domain, current trends, and most importantly your experience. The "GOOD" acid test for this continuum might simply be looking back at your previous work and if you say "sigh did I really solve it like that?" then chances are you are still growing and are likely to keep writing good code.

If you look back and see perfect code then either - you are perfect, and there is a risk you are stagnating and you may soon cease to write good code.

Answer 19

Release your code, let some people mess with it to make sure that it does what it's always supposed to. Or if you would like, design a spec and make sure it meets all of those specifications. If you pass one or both of these tests, then your code is "good for right now." For most people, your code will never be great, because you'll come back in a year and say "Why did I do that when it would've worked so much better this way?"

With more experience, you get better code. But if you continually practice the same habits, you'll continually fall into the same pitfalls. It's just a simple take on an old adage of "Practice makes permanent." If you continually do things the right way (like testing your code to always make sure it works for what it's supposed to do), then you'll get better. If you continually do things the wrong way (like never testing your code for certain situations, or failing to recognize where bugs could occur), you'll just get stubborn with your code.

Answer 20

Nothing beats having someone experienced look at your code, but there are some resources to help you evaluate and improve your code on your own. Take a look at Martin Fowler's Refactoring (or website). Sutter and Alexandrescu's C++ Coding Standards is good if you're writing in C++. A lot of the recommendations in there are language agnostic, but others may be able to recommend similar books for other languages. Test driven development can be very useful to solo developers, as it provides a sort of quality check as you go, and you know when tests become difficult to write that it means your code could probably use restructuring.

Some other signs are more process-oriented. They usually lead to better code, but not directly. These include things like use of source control, an automated build process, not developing directly on the live server, use of bug tracking software, etc.

Answer 21

You can use code analysis tool such as FindBugs, PMD. That will provide some information about your code's quality.

Answer 22

In effort to code well, I aim to ensure that the program is highly functional and speedy about it. Make sure everything is in a place it should be so that the file, data, function and abstractions are fairly obvious.

After this point I put it to a test: Find a person fairly unversed in computers in general, try to explain some of the main code pattern. If they can sorta-kinda read it, wow. Good job.

Mostly just KISS and try to be innovative without crashing anything. I would also make more notes about coming back to the code and having a nice time improving and maintaining it, but that has been covered pretty well.

Answer 23

Never.

"Good code" is only code for which no way of improvement has been found yet. As Jeff Atwood said:

There are a handful of programmers in the world capable of producing brilliant, perfect code. All the rest of us can do is keep making our software less shitty over time-- a process of continuous improvement

And by the way, you don't have to reach the perfection, because sometimes, "Sufficent Design means poor design".

Answer 24

I use 5 points to know if code is good or not:

• procedure, method, and class names are both usefully short and yet tell me what they do.
• commenting out any include causes failure to run
• looking at the code after a month away, I can follow the flow
• code compiles and runs cleanly.
• program performs the intended actions and only the intended actions.

For me, GetCustIDFromDB(var* DB, char* customer) is better than getcid(var* DB, char* c) because it tells me what I'm looking at. But *DBLookupCIDByName(var* DB, char* customer) works, too.

I often test to see if I actually still use all my #includes... If I can remove it, great. Sometimes, it's possible to examine your included headers, and see if the needed functions are actually in something that header includes via #include instead... but I've only done that rarely, and it saves a little bit of space, too, tho' it may make the process of adding new features much harder.

Answer 25

It is a hard thing to say. There's always a question of taking longer to do it right, or taking less time and getting it done sooner so you can work on other things.

http://xkcd.com/844/

I've gone back and looked at code I did a few years ago, and I think it looks awful. We are constantly learning in this field, and the best way to code right is to look at other people's examples and learn from them. Once you learn something new, share it with others so that we all can benefit from it.