How do you know it's good code - Interview Question.

Question

During a phone interview someone asked the question, "When looking at code, what's the first thing that stands out to let you know it's from a good/experienced developer?"

I believe my answer was sufficient, just thought it was a bit strange so I'm curious how some of you would answer?

EDIT: thank you for all the answers. One of the reasons why I asked this here is only because many of these answers are the same that I started saying but they interviewer would constantly interrupt me to reiterate, "YES, but what is the FIRST thing?" which lead me to believe that my answer was not what he was looking for.

Answer 1

Each function does exactly one thing.

Answer 2

Does it have unit tests? Unit tests have many benefits and are usually a good sign of code quality:

• They help separate the code into reusable units that are independent of each other.
• They provide up-to-date documentation for the code. Comments, on the other hand, can quickly become out of date.
• They make the developer think more of failure modes and error handling.
• They make refactoring easier and safer.

Answer 3

Three things:

1. Comments
2. Comments
3. Comments

Did I mention "comments"?

Update: Seriously? This negative a reaction to the idea that well-commented code is a valid indicator of a good and experienced (I'd add professional) developer?

Did I accidentally log in to the Bizarro StackOverflow or something? I have a question for all the down-voters:

If a job candidate submitted a code sample that included no comments whatsoever, would you conclude a) the candidate is the most brillant programmer in history, or b) the candidate has never worked in a professional code shop?

Remember that the original question was (to paraphrase) "what single feature of code lets you best evaluate a developer's ability and experience?", not "do the most awesomest programmers need to use comments or not?"

Update 2: So far, my favorite comment on why comments (in code) are bad is this one from Tom Cabanski:

Inexperienced programmers read the comments and get fooled.

I never thought of it this way. I'm going to stop putting comments in my code, and I'm also going to stop giving my variables descriptive names, since the names (which are just a convention not enforced by the compiler) might fool inexperienced programmers. And no more documentation of any kind, since that might fool inexperienced programmers too.

It's weird, though, because I always thought that the whole point of comments/naming conventions/documentation etc. was to help other programmers understand what your code is doing and why (as well as why you're not doing it some other way). I guess the great ones just don't need crutches like this.

Answer 4

I look for good error handling. Inexperienced developers often write code that assume everything will go right. Experienced developers will check parameter/code contracts and add plenty of error handling to deal with what can go wrong.

Answer 5

Does it smell good ?

Answer 6

The structure tells you a lot. Without even reading the code you can tell its quality by whether or not it has deep nesting.

Answer 7

amongst other things...

• predominantly short methods
• relatively flat left margins - deep nesting a sign of poor design.

Answer 8

A lot of good/experienced developers write code that I hate reading, so there is really no way to determine whether someone is good with a cursory glance.

My own preferences are:

• short functions (generally less than ten lines long), each with a single clear task
• avoid nesting too deep
• good names for classes, functions, variables, etc.
• has easy-to-find "hooks" for adding new functionality
• idiomatic (That is, if it's C++, then it looks like C++ should look; if it's Java, then it looks like Java should look.)
• makes good use of standard library/framework (I don't like seeing wheels reinvented.)
• no unnecessary comments (which are the mark of someone who can't really think in code)
• good use of whitespace

Adhering to these preferences doesn't guarantee the person is a good/experienced developer, but it does give me a good first impression. Someone who takes care to get these things right probably does a lot of other stuff right too.

You don't really know how good someone's code is until you try to change it. I've seen code that was really ugly which nevertheless was easily maintainable, and I've seen pretty code that had to be thrown away and rewritten from scratch. Reviewing code gives you a good feel for a programmer's tactical abilities, but not strategic abilities.

Answer 9

I take into consideration the following when viewing code, if the following is true, it's 'good' code in my eyes.

• Well formatted/consistent
• Well factored
• Nice use of spacing
• Methods not too long - should fit on one page/no need for scrolling at worst
• Modular/Testable - otherwise it's a nightmare to unit test
• Is the code SOLID? - hard to tell from a quick glance, but you can see some principles being broken if a class is large, or there is a lot going on for example.

All code should look as if one developer produced it. There is nothing worse than seeing several styles of coding within one source file. Even worse when only one developer produced it! The other points are a given really, but you could add any other code smells to that list.

Answer 10

Good code should flow like a good conversation. While Literate Programming can be overkill in some cases, the philosophy should always be present.

My rules would contain:

• Say what you mean
• Don't try to be clever
• Add comments, but don't exaggerate
• Indent and space cleanly
• Don't try to be clever
• Don't try to be clever

The Zen of Python provides good advice on what to look for in good code (regardless of the language).

Answer 11

Good variable names.

Concise.

Minimal comments (method and variable names should do most of the explanation).

As soon as anything non-obvious is done, then it should be extensively commented.

Answer 12

First thing? Squint (or imagine squinting). Does it look good?

Obviously good code is more than formatting. But in order to have good code, it is necessary for the code to be well formatted, obeying conventions and not a big incoherent mess. That will whittle away most really bad code.

Answer 13

if I understand what the code does at first look, the developer of the code rocks!

(because understanding is the reason why I look at the code and it includes the level of mess, the goodness of the structure, comments, indentation, the cohesion of the code and even exception handling)

Answer 14

Interesting question. Reflecting on it, I think a lot of it boils down to clarity of purpose:

• Is it clear what this class is meant to represent (I'm assuming OO code here)
• Is that purpose sufficiently limited in scope (not trying to do too much)?
• Is the purpose of each variable clear?
• Is the purpose of each method clear?

If all of those are true, it's probably reasonable code to maintain - and that's the sign of a good developer, IMO.

I'd also look for testability... that's a slightly different set of criteria, but limiting the scope of each class (and keeping it clear) is certainly a good start.

Answer 15

if :

1) Every function does exactly the same thing 2) There is an ample description in comments especially about the function signature and what various elements in the signature mean with respect to the problem domain 3) Re-usable, abstracted code

Answer 16

It takes time to recognize good code. Bad code can be recognized immediately. Short code files, classes and methods are good signs and so is good formatting, but it is only superficial. Anyone can split up large methods into small ones, but if the program is unclear it will only become slightly clearer.

One 50-line method is usually better than 200 1-line methods, even if 25 short methods might have been the optimal solution.

I've seen a lot of superficially good code, which had a well thought-out architecture, but where the algorithms were bad and/or unclear. A good program should be well-designed in every respect, but it is hard to identify a good program without really working with it.

Answer 17

Readability. [allows easy maintenance]

If the code is easy to read it doesn't need to looks ingenious (one long complicated line) and take the reader time to review to understand it.

The faster someone can look at it and understand it. The faster the application will move forward (feature and revenue).

Answer 18

Quote from Ward Cunningham:

You know you are working on clean code when each routine you read turns out to be pretty much what you expected.

Which in turn was commented (in the above link) by Uncle Bob:

Statements like this are characteristic of Ward. You read it, nod your head, and then go on to the next topic. It sounds so reasonable, so obvious, that it barely registers as something profound. You might think it was pretty much what you expected. But let's take a closer look.

". . . pretty much what you expected." When was the last time you saw a module that was pretty much what you expected? Isn't it more likely that the modules you look at will be puzzling, complicated, tangled? Isn't misdirection the rule? Aren't you used to flailing about trying to grab and hold the threads of reasoning that spew forth from the whole system and weave their way through the module you are reading? When was the last time you read through some code and nodded your head the way you might have nodded your head at Ward's statement?

Ward expects that when you read clean code you won't be surprised at all. Indeed, you won't even expend much effort. You will read it, and it will be pretty much what you expected. It will be obvious, simple, and compelling. Each module will set the stage for the next. Each tells you how the next will be written. Programs that are that clean are so profoundly well written that you don't even notice it. The designer makes it look ridiculously simple like all exceptional designs.

Answer 19

For me:

• Concise but readable code.
• Functions have as few state-changing side-effects as practical.
• The state-changing side-effects that do exist are unsurprising.
• Code makes few assumptions about the objects it interacts with. The assumptions that are made are enforced by well-designed contracts or interfaces.
• The code is idiomatic and follows community conventions for the language used.
• The code closely reflects the language of the problem domain, at least where it's appropriate (as in a "domain layer").
• Static variables, when used, don't introduce temporal coupling issues.
• Use of "clever" features of the language improves, rather than detracts, from readability.
• The behavior of objects in the system (presuming an object-oriented system) is unsurprising.

And finally, presuming this is code from a living, rather than dead, organization:

• The inevitable compromises between the idealized code we'd like to be reading and the code that we must maintain should be defensible by reasonable people, and not simply a product of stagnation or ignorance.
• The developers still working on the system have at least some ideas for improving the pain points in the design that won't completely undermine the existing design. (If the only way to improve things is to throw most of it away, it can't be good code).

Answer 20

Though I don't disagree with these answers, I would say they are more of an indication of wither a coder is "good" at working with others. Does how does he dress and what is his personal hygiene really have anything to do with code quality? What if the guy wrote an entire cms in 3 lines of undecipherable bash script or something like that, is his code good? I think the honest answer would be there really is no way that does include the context of the code submitted. Was this a prototype? Is this a modification of someone elses code? I have seen a function with code from two people and the only thing wrong with it is that it looked like two people worked on it. Who knows what kind of answer the interviewer was looking for in any case. Who really wants to hear the existential truth about things.

Answer 21

The very first thing, before I even start reading the code would be code indentation.

Answer 22

I would put him no hold and go do my laundry.

Answer 23

The function and variables names sufficiently explain what is going on, the comments explain why the code is a certain way.

Answer 24

I think that he was look for a single line answer, could be:

• It looks elegant

Maybe he was trying to find out if you were a "software craftsman", then trully good code is a work of art, it is more something that you feel, than something that you analyse.