• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

What Are the Hallmarks of Good / Bad Code?

C

chrstrbrts

Senior member
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.
 
Last edited:
chrstrbrts said:
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.
Click to expand...

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.
 
Markbnj said:
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.
Click to expand...

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.
 
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.
 
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.
 
chrstrbrts said:
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.
Click to expand...
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.
 
Spungo said:
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.
Click to expand...

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.
 
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.
 
smackababy said:
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.
Click to expand...
Agreed 100%.

Try adding features you've never added before. Eventually something will break and you'll need to search for the problem.
 
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 said:
Underscores are good for constants, since they should be all caps. It helps with readability.
Click to expand...

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:
Code: 
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
Code: 
class MyClass { .... }

3) Private methods are written in camel case. Public methods are written in pascal case.
Code: 
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.
Code: 
public void WriteData(string myFile, string myData) { ... }


I think there's also a general rule about global variables starting with a g.
 
Last edited:
chrstrbrts said:
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.
Click to expand...

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.

Spungo said:
This raises a good question. What's the general standard for naming things?
Click to expand...

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
 
Last edited:
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).
 
smackababy said:
Underscores are good for constants, since they should be all caps. It helps with readability.
Click to expand...

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.
 
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.
 
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.
 
mikeymikec said:
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).
Click to expand...
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.
Code: 
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).
Click to expand...
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.
 
purbeast0 said:
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.
Click to expand...

You shouldn't ever try to write Ruby code then... lol. 😀
 
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.
 
You must log in or register to reply here.

TRENDING THREADS

Back
Top