|
|
|
SSC-Dedicated
           
Group: Administrators
Last Login: Today @ 5:09 AM
Points: 31,526,
Visits: 13,864
|
|
|
|
|
|
Forum Newbie
      
Group: General Forum Members
Last Login: Tuesday, October 04, 2011 2:05 AM
Points: 2,
Visits: 8
|
|
Well I personally use code smells to measure quality of code. To me one of the worst examples of bad code is when the same logic or even same piece of code is present several places.
One of the worst things I've encountered was having the same logic in C# and in SQL, being used in different circumstances. That meant that if you wanted to change something you'd had to change it in at least two locations, and it was hard to ensure that all scenarios was covered.
|
|
|
|
|
SSC Rookie
      
Group: General Forum Members
Last Login: Tuesday, June 11, 2013 11:07 AM
Points: 42,
Visits: 172
|
|
WTFs/minute sounds like a good measurement. Exceptional code can be measured in days between WTFs, really good code can be measured in WTFs/hour and really poor code in WTFs/second.
|
|
|
|
|
Forum Newbie
      
Group: General Forum Members
Last Login: Tuesday, October 04, 2011 2:05 AM
Points: 2,
Visits: 8
|
|
Dennis Wagner-347763 (2/21/2011) WTFs/minute sounds like a good measurement. Exceptional code can be measured in days between WTFs, really good code can be measured in WTFs/hour and really poor code in WTFs/second.
That's essentially just hertz. In theory you could then have GHz code - although in practice it will more likely be in µHz (mikrohertz).
|
|
|
|
|
SSC-Addicted
      
Group: General Forum Members
Last Login: Thursday, October 13, 2011 9:15 AM
Points: 480,
Visits: 95
|
|
You measure quality in code the same way you measure quality in science, through peer review.
In .Net development (and I'm sure in other languages/platforms) we have static code analyzers that can help by pointing you towards potential problems. But the best way to ensure good quality code is through code reviews. These can be quick and informal like "Can you take a look at this before I check it in?", or they can be more formal where and reviews a piece of code that one person wrote.
The group reviews can turn ugly, and that needs to be kept under control, but they can also be educational as everyone gets to see what other people are doing that's right and wrong, and hopefully clean up in their own code as a result.
|
|
|
|
|
SSC Rookie
      
Group: General Forum Members
Last Login: Tuesday, June 11, 2013 11:07 AM
Points: 42,
Visits: 172
|
|
Obviously my first post was just in jest.
While peer review isn't really a true measurement because it's subjective (like judges in the Olympics -- yecch), it is a great way to bring a team together cohesively. The best team environment I ever worked in had multi-phased code reviews (algorithm, psuedo-code, development code, production code) by at least two team members -- and not always the same ones. We strived to achieve the following:
1) Each piece of code did one thing and one thing only 2) Each piece of code was similar in look and feel to all other code to make maintenance easier 3) Never have more than one copy of code that does the same thing.
We had one rule for code review -- keep your personal feelings about another person out of the room -- be objective. We delivered the project on time and with very little defects.
|
|
|
|
|
Say Hey Kid
      
Group: General Forum Members
Last Login: Friday, June 14, 2013 10:50 AM
Points: 691,
Visits: 1,724
|
|
Most of these rules successfully separate gawdawfull code from adequate code. Separating adequate code from good or great code is a lot more difficult.
How do you differentiate a technically proficient painting from a great one, or a decent piano from a great one, or a decent meal from a great one? Rules don't help so much there but we can often sense the difference when we encounter it. Alas the same thing happens with code.
...
-- FORTRAN manual for Xerox Computers --
|
|
|
|
|
Mr or Mrs. 500
      
Group: General Forum Members
Last Login: Today @ 6:42 AM
Points: 504,
Visits: 2,530
|
|
mhli (2/21/2011)
Dennis Wagner-347763 (2/21/2011) WTFs/minute sounds like a good measurement. Exceptional code can be measured in days between WTFs, really good code can be measured in WTFs/hour and really poor code in WTFs/second.
That's essentially just hertz. In theory you could then have GHz code - although in practice it will more likely be in µHz (mikrohertz).
I think "hurtz" would be a better name. If you have mHurtz code then you've got problems, but GHurtz...now you're in serious pain.
|
|
|
|
|
Ten Centuries
      
Group: General Forum Members
Last Login: 2 days ago @ 7:18 AM
Points: 1,322,
Visits: 1,077
|
|
Most of these rules successfully separate gawdawfull code from adequate code. Separating adequate code from good or great code is a lot more difficult. Separating good from great code is certainly more difficult, but also less necessary.
How do you differentiate a technically proficient painting from a great one, or a decent piano from a great one, or a decent meal from a great one? Rules don't help so much there but we can often sense the difference when we encounter it. Alas the same thing happens with code
I disagree. Part of the reason that experts can distinguish between good and great is because they have a language to discuss the differences with. An amateur may know what they like and don't like but has difficulty describing the what and why of their opinion. To take the piano example, the amateur may be able to tell you that one piano sounds better to them, the expert will be able to talk about the nuances of the sound that make it sound better (harmonic range, sound board reverberation, etc.) Certainly, experts may disagree on the weight to give various aspects of an artistic endeavor, but that doesn't invalidate the process itself.
Likewise, there are aspects of computer code that make one piece of code better than another, the lowest level distinction is, of course, works versus fails. Beyond that there are measures of maintainability, efficiency (O notation), reusability, coupling, cohesion, documentation, etc.
In database design, the ability to add objects or elements without having to rework large swaths of existing code is certainly an aspect of the quality of the design that the beginner often fails to recognize but that the expert does. -- JimFive
|
|
|
|
|
Ten Centuries
      
Group: General Forum Members
Last Login: Today @ 11:14 AM
Points: 1,185,
Visits: 3,418
|
|
The problem with metrics is that most company's simply don't have an official standard. Ask ten different managers (in the same department) to examine a piece of code, and you'll get 10 different opinions about about how well it conforms to their personal standard. Most managers keep their standards only inside their head, so it even evolves over time. Just like food in a restraunt, the end users are the final judge of the quality of your code.
"Winter Is Coming"
|
|
|
|