What Are the Hallmarks of Good / Bad Code?

[chrstrbrts]

Hello,

I'm new to computers, and at this point my metric for what constitutes good programming is functionality. That is, if a piece of code simply does what it's supposed to, in my eyes it's good.

However, I'm aware enough to understand that even though code may be functional, it may still be poorly constructed.

So, experienced programmers, how do you know when looking at source code whether or not the writer knew what he was doing?

What are the hallmarks of good programming? What are the hallmarks of bad programming?

Can you recommend certain coding styles to emulate? Can you admonish me from emulating others?

Thanks.

 

[Markbnj]

I'm new to computers, and at this point my metric for what constitutes good programming is functionality. That is, if a piece of code simply does what it's supposed to, in my eyes it's good.

I've worked with a couple of people like that. This is not an easy question to answer. Good code does what it is supposed to do, that is still the primary criteria. But good code also is minimal, cohesive, modular, clear, efficient and comprehensible. It's sort of like that old definition of obscene: you'll know it when you see it.

 

[chrstrbrts]

I've worked with a couple of people like that. This is not an easy question to answer. Good code does what it is supposed to do, that is still the primary criteria. But good code also is minimal, cohesive, modular, clear, efficient and comprehensible. It's sort of like that old definition of obscene: you'll know it when you see it.

Thanks. I just finished my first real program, and it's spaghetti-ish as all hell. Over 10, 000 lines of code, over 15 separate class files, etc.

My code works, but looks terrible. I realized that you should really plan your code out first before actually writing it.

Oh, well. It's my first rodeo, and I'm still learning.

 

[Rakehellion]

When I first started I wrote a lot of programs that worked, but I didn't know they worked a month later so I couldn't edit them to add features. Boy, did that suck.

 

[DaveSimmons]

It depends on the use and how long the code might be kept. Writing for a textbook vs. a power plant vs. a hipster website that disruptively reinvents itself weekly with locally-sourced coders.

At work we are still using code that I wrote in 1999.

Good code for business use needs to be maintainable, because you might be stuck with it for decades. An hour saved now might cost you tens of hours over the life of its use.

But good code for business use is also done when you need it to be. Sometimes you need to save that hour now, knowing that you will pay for it later.

 

[Spungo]

Thanks. I just finished my first real program, and it's spaghetti-ish as all hell. Over 10, 000 lines of code, over 15 separate class files, etc.

My code works, but looks terrible. I realized that you should really plan your code out first before actually writing it.

My code looks like that too.

The best way to learn is to get no instructions at all. Eventually you'll get sick of your own garbage code and you'll find a way to make code that is easier to read. Things will get worse before they get better.

 

[smackababy]

My code looks like that too.

The best way to learn is to get no instructions at all. Eventually you'll get sick of your own garbage code and you'll find a way to make code that is easier to read. Things will get worse before they get better.

I think a good exercise is to go back and add functionality to existing projects you've done months ago, rather than constantly start new ones. You will have to either stop writing code that is unreadable or constantly bare frustrated.

 

[KWiklund]

For good coding, I'd look at modularity both horizontally and vertically. Vertical partitioning of your design is desirable since it allows you to separate high- and low-level functionality. For example, splitting desired application behaviour, and lower level services that may be platform/device specific. In the other direction, you also want to make your modules to be as independent of each other as is reasonably possible. Each module should perform a well-defined role.

In terms of general coding, I would recommend the MISRA guidelines as much as is reasonable. Although these guidelines were developed for embedded programming in the automotive industry, they still represent good practice in a variety of contexts.

 

[Spungo]

I think a good exercise is to go back and add functionality to existing projects you've done months ago, rather than constantly start new ones. You will have to either stop writing code that is unreadable or constantly bare frustrated.

Agreed 100%.

Try adding features you've never added before. Eventually something will break and you'll need to search for the problem.

 

[purbeast0]

do not use underscores in variable names ... that is bad code!

(semi serious about this too, i can't stand it - camel case ftw!)

 

[smackababy]

do not use underscores in variable names ... that is bad code!

(semi serious about this too, i can't stand it - camel case ftw!)

Underscores are good for constants, since they should be all caps. It helps with readability.

 

[Spungo]

Underscores are good for constants, since they should be all caps. It helps with readability.

This raises a good question. What's the general standard for naming things?

From what I've seen in books, it goes like this:
1) Private properties begin with an underscore and public properties do not:

class MyClass {
   private string _property;       //for internal use
   public string Property {        //how other things will interact with it
      get { _property; }
      set { _property; }
   }
}

2) Classes are always pascal case

class MyClass { .... }

3) Private methods are written in camel case. Public methods are written in pascal case.

private void writeData () { ... }
public void WriteOtherDate() { ... }

4) Narrow scope variables are written in camel case. These often start with "my" because that's a quick and easy way to make a camel case name that doesn't conflict with keywords.

public void WriteData(string myFile, string myData) { ... }

I think there's also a general rule about global variables starting with a g.

 

[beginner99]

Hello,

I'm new to computers, and at this point my metric for what constitutes good programming is functionality. That is, if a piece of code simply does what it's supposed to, in my eyes it's good.

However, I'm aware enough to understand that even though code may be functional, it may still be poorly constructed.

So, experienced programmers, how do you know when looking at source code whether or not the writer knew what he was doing?

What are the hallmarks of good programming? What are the hallmarks of bad programming?

Can you recommend certain coding styles to emulate? Can you admonish me from emulating others?

Thanks.

Follow the conventions of a) the language and b) your organization and then be consistent. This goes for naming and style conventions (like space after/before }, line length,...
Also give variable meaningful names and not just a,b,c,d,e,...I hate pseudo-Hungarian notation like iStart where the "i" marks the variable as integer.

Also if a class or method becomes too large it's a possible sign of breaking certain principles. If a method is more than 200 LOC you should have a closer look at it and probably break it into multiple methods. For classes at 1000 LOC I would check for breaking these principles as well. But LOC isn't that good of a measurement. It's a very vague indication when you need to have a closer look.

https://en.wikipedia.org/wiki/Single_responsibility_principle

http://c2.com/cgi/wiki?LawOfDemeter

http://c2.com/cgi/wiki?TooManyParameters

etc. (see https://stackoverflow.com/questions/2050171/recommended-number-of-lines-per-java-source-file)

EDIT:

Still even if you follow all this it doesn't mean your writing good code. Also in general good code can take longer to write.

And then there is also the standard project management principle. You ever only can choose 2 of the following 3:

- Fast (Time to Market)
- Cheap
- Quality

So if you want something on the market fast for cheap (the standard requirement set by managers with 0 clue) your products (software) quality will plainly suck.

This raises a good question. What's the general standard for naming things?

There are different standard for different languages.

for example:

Java:
http://www.oracle.com/technetwork/java/javase/documentation/codeconvtoc-136057.html

C#:
http://msdn.microsoft.com/en-us/library/ff926074.aspx

 

[mikeymikec]

A couple of examples of bad practice:
Hard-coding values where you should have used variables (a really basic example would be your country's current sales tax %, or say a value that you're using repeatedly in your code yet you're hard-coding it).

Code based on assumptions where things should be instead of asking the system where those things are (e.g. assuming that the user profile folder is located in a certain place rather than asking the system where the current user's profile is).

 

[purbeast0]

Underscores are good for constants, since they should be all caps. It helps with readability.

yeah, that is the only time it's ever okay. can't stand when people start variables with _ or between words, unless constant of course. but i do realize that is kind of the paradigm of some languages for private variables and stuff. still i hate it.

 

[BoberFett]

Personally I sometimes think that over-architect my code. I use a more complex object structure than might be necessary, and focus more and clarity than absolute balls to the wall optimization and speed. But I have gotten comments from people that took over after I've left companies saying that they thought my code was well written and easy to maintain.

 

[IHateMyJob2004]

Good code in acadamia is one thing. Good code in the real world is another. You should strivefor clean code but time, man hours and experience of employees impact results.

 

[chrstrbrts]

Thanks, everyone.

 

[Spungo]

A couple of examples of bad practice:
Hard-coding values where you should have used variables (a really basic example would be your country's current sales tax %, or say a value that you're using repeatedly in your code yet you're hard-coding it).

Microsoft Excel. I'm really glad I had a computer teacher who was brutal about putting constants in a table and having everything referencing the table. Her assignments were easy to do, but there was always a very clearly defined area to put values. She would put an Excel file on the server that is used as a template for the Excel exercise, and this template would have slots for all of the variables. If you were using numbers outside of the designated area for constants, it was marked wrong. It doesn't matter if you still get the correct number. It's still marked wrong. Lesson: constants go at the top of the Excel sheet, and everything using those numbers points to the cell.

I imagine code would get really bad if nobody left comments saying what the numbers meant.

speed2 = speed1 / 3.6;     //good luck figuring out where 3.6 came from

Divide by 3.6 when converting km/h velocity to m/s

Code based on assumptions where things should be instead of asking the system where those things are (e.g. assuming that the user profile folder is located in a certain place rather than asking the system where the current user's profile is).

I hate how programs do the opposite of this when they write to the registry. Instead of the program listing the exact location it installed to, the program will have a vague description of where it was installed. Maybe it will say %PROGRAMDIR%\AutoCAD of something. what happens if you change the program directory so things default install to a different hard drive? Now all of the previous installations are broken because the software assumed the default directory would never change.

 

[Crusty]

yeah, that is the only time it's ever okay. can't stand when people start variables with _ or between words, unless constant of course. but i do realize that is kind of the paradigm of some languages for private variables and stuff. still i hate it.

You shouldn't ever try to write Ruby code then... lol.

 

[disappoint]

do not use underscores in variable names ... that is bad code!

(semi serious about this too, i can't stand it - camel case ftw!)

bool camelCase=true;

 

[IHateMyJob2004]

caleCase should be used if it is the languages standard. Or the standard of the company, group or organization.

 

[purbeast0]

You shouldn't ever try to write Ruby code then... lol.

never done ruby but done tons of groovy.

 

[Paul Williams]

The code should be precise and easy to understand!!

 

[dagamer34]

Writing "good" code is a skill. I don't think there's an easy way to get there without experience, and that's really only gained by working on projects either at a job or on your own. Like all things, you must actually DO the thing you want to improve on, not just read about it in a book, blogpost, or web forum.

Probably the best line I've heard is this: "Code like the next person looking at what you write knows where you live and could murder you."

It's a bit graphic, but I think it gets the point across.