Quality of code
-
Rage wrote:
That sounds a bit exaggerated to me.
Sounds spot on to me. Here's a function pulled at random from the zlib library:
local int recmatch(p, s)
uch *p; /* sh pattern to match */
uch *s; /* string to match it to */
/* Recursively compare the sh pattern p with the string s and return 1 if
they match, and 0 or 2 if they don't or if there is a syntax error in the
pattern. This routine recurses on itself no deeper than the number of
characters in the pattern. */
{
loop */
/* Get first character, the pattern for new recmatch calls follows */
c = *p++;/* If that was the end of the pattern, match if string empty too */
if (c == 0)
return *s == 0;/* '?' (or '%') matches any character (but not an empty string) */
#ifdef VMS
if (c == '%')
#else /* !VMS */
if (c == '?')
#endif /* ?VMS */
return *s ? recmatch(p, s + 1) : 0;/* '*' matches any number of characters, including zero */
#ifdef AMIGA
if (c == '#' && *p == '?') /* "#?" is Amiga-ese for "*" */
c = '*', p++;
#endif /* AMIGA */
if (c == '*')
{
if (*p == 0)
return 1;
for (; *s; s++)
if ((c = recmatch(p, s)) != 0)
return (int)c;
return 2; /* 2 means give up--shmatch will return false */
}#ifndef VMS /* No bracket matching in VMS */
/* Parse and process the list of characters and ranges in brackets */
if (c == '[')
{
int e; /* flag true if next char to be taken literally */
group */
int r; /* flag true to match anything but the range */if (\*s == 0) /\* need a character to match \*/ return 0; p += (r = (\*p == '!' || \*p == '^')); /\* see if reverse \*/ for (q = p, e = 0; \*q; q++) /\* find closing bracket \*/ if (e) e = 0; else if (\*q == '\\\\') e = 1; else if (\*q == '\]') break; if (\*q != '\]') /\* nothing matches if bad syntax \*/ return 0; for (c = 0, e = \*p == '-'; p < q; p++) /\* go through the list \*/ { if (e == 0 && \*p == '\\\\') /\* set escape flag if \\ \*/ e = 1; else if (e == 0 && \*p == '-') /\* set start of range if - \*/ c = \*(p-1); else {Well except for the short variable names, I would consider this well written and well doccumented code.
John
-
I think the problem with a lot of open source code is not that there isn't a variable naming convention, but rather that there are lots. Every developer thinks their way of doing things is the best, so uses his/her own coding style and naming standard, regardless of the existing style(s) in place. You get this much less in commercial organisations, since a coding style is usually mandated at some level, and unlike open source development, can be enforced where necessary ("follow the standards or find another job")
As long as 1) They are consistent, and 2) Their scheme is readable. My reasoning is simple, good developers are creative. One of the most laughable things I have seen is a massive organization with a system too large for its own good imploding ... but at least its consistent. If large organizations spent as much time on code quality as they did consistency there would be a lot better code. One of my fondest memories of Satan is the code review I sat in on were no one discussed logic; it was an architect nit-pick session where each one pointed out his personal preferences in how to write the code, none of them mentioned the logic error. When I mentioned the logic error I was reprimanded for not being a team player and told we don't have the time for that! The ultimate irony is that the person that usually ends up writing the standard that gets enforced is not the best, brightest, or most knowledgeable. They are just the only person willing do it, then this standard becomes an unholy bible from which a developer cannot deviate and unfortunately since so many developers are non-confrontational it seems they would rather code to failure than to stand up to something that is wrong. If you really want good software, do code reviews that focus on logic only and let the "standard" coalesce on its own without an official document. Sure you will get some bad stuff, just like in open source, however, open source software seems to be so much more reliable than some of the "enterprise" systems I have worked on. I guess the moral is that sometimes, it is ok to not be in control.
Need a C# Consultant? I'm available.
Happiness in intelligent people is the rarest thing I know. -- Ernest Hemingway -
I've just written a (scurrilous) entry with reference to Fortran77 - however what you describe sounds wierdly familiar:
John Simmons / outlaw programmer wrote:
The names they use rarely indicate what they might represent, and most of them are limited to just two letters
Well you are well ahead of the game here - in F-77 2 chars were only used when you had run out of one char possibilities :-D
John Simmons / outlaw programmer wrote:
There are almost NO comments.
/*COMMENTS - WHEN I WAS A LAD ...*/ REM :laugh:
John Simmons / outlaw programmer wrote:
They made widespread use of the much hated goto.
And how else should I control non-deterministic program control flow? OUCH Ahh - thats better :)
"I know you believe you understood what you think I said, but I am not sure you realize what you heard is not what I meant."
modified on Thursday, August 14, 2008 3:28 PM
AlphaMatrix wrote:
And how else should I control non-deterministic program control flow?
Um... intelligently and readably ?
Christian Graus No longer a Microsoft MVP, but still happy to answer your questions.
-
I downloaded the source code to ffmpeg (written entirely in C), and was perusing the code associated with the ffplay utility. 0) The variable naming conventions they use quite frankly suck. The names they use rarely indicate what they might represent, and most of them are limited to just two letters. 1) There are almost NO comments. Well, there are so few comments as to validate the claim of "no comments", but since there are a few comments, and since programmers by their nature are a pedantic lot, "almost no comments" is technically the more correct phrasing. 2) They made widespread use of the much hated
goto. I don't know why, but I'm completely surprised at the almost complete lack of comments and the variable naming convention."Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 -
As long as 1) They are consistent, and 2) Their scheme is readable. My reasoning is simple, good developers are creative. One of the most laughable things I have seen is a massive organization with a system too large for its own good imploding ... but at least its consistent. If large organizations spent as much time on code quality as they did consistency there would be a lot better code. One of my fondest memories of Satan is the code review I sat in on were no one discussed logic; it was an architect nit-pick session where each one pointed out his personal preferences in how to write the code, none of them mentioned the logic error. When I mentioned the logic error I was reprimanded for not being a team player and told we don't have the time for that! The ultimate irony is that the person that usually ends up writing the standard that gets enforced is not the best, brightest, or most knowledgeable. They are just the only person willing do it, then this standard becomes an unholy bible from which a developer cannot deviate and unfortunately since so many developers are non-confrontational it seems they would rather code to failure than to stand up to something that is wrong. If you really want good software, do code reviews that focus on logic only and let the "standard" coalesce on its own without an official document. Sure you will get some bad stuff, just like in open source, however, open source software seems to be so much more reliable than some of the "enterprise" systems I have worked on. I guess the moral is that sometimes, it is ok to not be in control.
Need a C# Consultant? I'm available.
Happiness in intelligent people is the rarest thing I know. -- Ernest HemingwayHad something similar (again a large organisation), where the design review checklist was missing the obvious question "will the design work?"
Graham Librarians rule, Ook!
-
I downloaded the source code to ffmpeg (written entirely in C), and was perusing the code associated with the ffplay utility. 0) The variable naming conventions they use quite frankly suck. The names they use rarely indicate what they might represent, and most of them are limited to just two letters. 1) There are almost NO comments. Well, there are so few comments as to validate the claim of "no comments", but since there are a few comments, and since programmers by their nature are a pedantic lot, "almost no comments" is technically the more correct phrasing. 2) They made widespread use of the much hated
goto. I don't know why, but I'm completely surprised at the almost complete lack of comments and the variable naming convention."Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001Relax, John. Enhance your calm. Have a nice cool drink.
Best wishes, Hans
[CodeProject Forum Guidelines] [How To Ask A Question] [My Articles]
-
Relax, John. Enhance your calm. Have a nice cool drink.
Best wishes, Hans
[CodeProject Forum Guidelines] [How To Ask A Question] [My Articles]
:omg: I'll pass on that nice cool drink :laugh:
"The clue train passed his station without stopping." - John Simmons / outlaw programmer "Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
-
However, I haven't found a client yet that cares. I still author quality code or quit; however the vast majority of my peers do not have the same ethics.
Need a C# Consultant? I'm available.
Happiness in intelligent people is the rarest thing I know. -- Ernest HemingwayEnnis Ray Lynch, Jr. wrote:
However, I haven't found a client yet that cares.
From what I see, systems today are in place for only a few years. This is quite different from the way it was "way back". So there is no pressure to write quality code, because in a year or two it will just be scrapped. Although recently I was working on an embedded system, and saw revision dates going back more than ten years. I was quite surprised at how well-structured and commented the code was. Very easy to modify. One of my co-workers told me that was mainly because of the team leader, who held regular code walk-thrus, and kept a "coding hall of shame" on an internal web site.
Best wishes, Hans
[CodeProject Forum Guidelines] [How To Ask A Question] [My Articles]
-
I downloaded the source code to ffmpeg (written entirely in C), and was perusing the code associated with the ffplay utility. 0) The variable naming conventions they use quite frankly suck. The names they use rarely indicate what they might represent, and most of them are limited to just two letters. 1) There are almost NO comments. Well, there are so few comments as to validate the claim of "no comments", but since there are a few comments, and since programmers by their nature are a pedantic lot, "almost no comments" is technically the more correct phrasing. 2) They made widespread use of the much hated
goto. I don't know why, but I'm completely surprised at the almost complete lack of comments and the variable naming convention."Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001I agree with you on all points 1 & 2, I've had to fix a large amount of legacy and so-called professional code before I could use it - some call me a perfectionist for this but I always feel any piece of unreadble code lets a whole project down. As for GOTO statements I have always thought that they've had a bad press - true they can be quite destructive and make code hard to read if used badly, but if commented and used correctly they can actually save a lot of code and hacks to get round the workflow. Save the GOTO's!
-
However, I haven't found a client yet that cares. I still author quality code or quit; however the vast majority of my peers do not have the same ethics.
Need a C# Consultant? I'm available.
Happiness in intelligent people is the rarest thing I know. -- Ernest HemingwayI'm not worried about what the client thinks. I'm concerned about what maintenance programmers have to deal with.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 -
Ennis Ray Lynch, Jr. wrote:
However, I haven't found a client yet that cares.
From what I see, systems today are in place for only a few years. This is quite different from the way it was "way back". So there is no pressure to write quality code, because in a year or two it will just be scrapped. Although recently I was working on an embedded system, and saw revision dates going back more than ten years. I was quite surprised at how well-structured and commented the code was. Very easy to modify. One of my co-workers told me that was mainly because of the team leader, who held regular code walk-thrus, and kept a "coding hall of shame" on an internal web site.
Best wishes, Hans
[CodeProject Forum Guidelines] [How To Ask A Question] [My Articles]
Hans Dietrich wrote:
"coding hall of shame" on an internal web site
That is an awesome idea.
Software Zen:
delete this; -
I downloaded the source code to ffmpeg (written entirely in C), and was perusing the code associated with the ffplay utility. 0) The variable naming conventions they use quite frankly suck. The names they use rarely indicate what they might represent, and most of them are limited to just two letters. 1) There are almost NO comments. Well, there are so few comments as to validate the claim of "no comments", but since there are a few comments, and since programmers by their nature are a pedantic lot, "almost no comments" is technically the more correct phrasing. 2) They made widespread use of the much hated
goto. I don't know why, but I'm completely surprised at the almost complete lack of comments and the variable naming convention."Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001I have heard such arguments many times. "...Why he couldn't give me his code on a silver plate..." People often think that if you find someone elses code they can take it. People don't take under consideration that some one put a lot of work in developing that code. So what that they use not very clear naming conventions so they don't put comments, they use
goto. It's theirs choise becouse this is theirs code. When I develop something I really don't care if some one in the future will have problem reading it and understanding (if you want to use my work that's fine with me but I wan't you to work for it ;p to understand it, not just scroll thrugh it and decide - "that's it"). People tend to use things they have no idea of and if something goes wrong the blame the author. IF U DON'T KNOW WHAT IT IS THEN DON'T TUCH IT!!! this is what I'm always telling people. Take you time, study it, learn as much as posible about the thing and if after all that you'll don't understand how it works then I think it's time to realize this "toy" is not for you. Yes comments help. Nowdays people can do online and literaly copy paste someone elses work not even bothering to really study it. I myself avoid putting comments in my code. When I add them during development I remove them at the end. Comments, coding conventions, etc. ... they bind you to a schema. It's a lot more fun to code intuitively, to follow your guts when coding, when reading code samples without comments =]. -
I've just written a (scurrilous) entry with reference to Fortran77 - however what you describe sounds wierdly familiar:
John Simmons / outlaw programmer wrote:
The names they use rarely indicate what they might represent, and most of them are limited to just two letters
Well you are well ahead of the game here - in F-77 2 chars were only used when you had run out of one char possibilities :-D
John Simmons / outlaw programmer wrote:
There are almost NO comments.
/*COMMENTS - WHEN I WAS A LAD ...*/ REM :laugh:
John Simmons / outlaw programmer wrote:
They made widespread use of the much hated goto.
And how else should I control non-deterministic program control flow? OUCH Ahh - thats better :)
"I know you believe you understood what you think I said, but I am not sure you realize what you heard is not what I meant."
modified on Thursday, August 14, 2008 3:28 PM
AlphaMatrix wrote:
/*COMMENTS - WHEN
_I_WAS A LAD ...*/ REM [Laugh]... rich text commenting was not supported. Obnoxious lying old farts, next he'll be nattering on about walking to school 500 miles barefoot, uphill both ways, on a path made of crushed glass and poison ivy... :mad:
Today's lesson is brought to you by the word "niggardly". Remember kids, don't attribute to racism what can be explained by Scandinavian language roots. -- Robert Royall
-
As long as 1) They are consistent, and 2) Their scheme is readable. My reasoning is simple, good developers are creative. One of the most laughable things I have seen is a massive organization with a system too large for its own good imploding ... but at least its consistent. If large organizations spent as much time on code quality as they did consistency there would be a lot better code. One of my fondest memories of Satan is the code review I sat in on were no one discussed logic; it was an architect nit-pick session where each one pointed out his personal preferences in how to write the code, none of them mentioned the logic error. When I mentioned the logic error I was reprimanded for not being a team player and told we don't have the time for that! The ultimate irony is that the person that usually ends up writing the standard that gets enforced is not the best, brightest, or most knowledgeable. They are just the only person willing do it, then this standard becomes an unholy bible from which a developer cannot deviate and unfortunately since so many developers are non-confrontational it seems they would rather code to failure than to stand up to something that is wrong. If you really want good software, do code reviews that focus on logic only and let the "standard" coalesce on its own without an official document. Sure you will get some bad stuff, just like in open source, however, open source software seems to be so much more reliable than some of the "enterprise" systems I have worked on. I guess the moral is that sometimes, it is ok to not be in control.
Need a C# Consultant? I'm available.
Happiness in intelligent people is the rarest thing I know. -- Ernest HemingwayEnnis Ray Lynch, Jr. wrote:
I guess the moral is that sometimes, it is ok to not be in control.
True, but then you could also say that the moral is, if you don't want to be following a crummy set of standards, don't blow off putting them together. The nit-pick sessions are definitely useless wastes of time (enforcing the standard is good, but those pesky logic errors...), but consistent and good (and consistently good, for that matter) style and structure should make those logic errors easier to find and fix. Unfortunately, as you said, the "best and brightest" often don't want to be bothered either writing or following a standard unless it's a big one they can turn around and bash their favorite target for not following (be it MS, F/OSS, or just another team in the same office). Kind of makes you wonder just how best and bright they are, but... Standards, unfortunately, rarely just coalesce in a lot of the settings where they are most useful... so people really do need to take more interest in helping make them relevant and to stick with them. That way when it is time to do the review standards issues are quick and easy to clear up (because people are following directions in the first place) and you *can* just focus on logic (which will be easier because everyone will be familiar with where things are in the code).
-
I downloaded the source code to ffmpeg (written entirely in C), and was perusing the code associated with the ffplay utility. 0) The variable naming conventions they use quite frankly suck. The names they use rarely indicate what they might represent, and most of them are limited to just two letters. 1) There are almost NO comments. Well, there are so few comments as to validate the claim of "no comments", but since there are a few comments, and since programmers by their nature are a pedantic lot, "almost no comments" is technically the more correct phrasing. 2) They made widespread use of the much hated
goto. I don't know why, but I'm completely surprised at the almost complete lack of comments and the variable naming convention."Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 -
I'm not worried about what the client thinks. I'm concerned about what maintenance programmers have to deal with.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001A consistent Charlie Foxtrot is much worse for maintenance than an inconsistent application that is written well.
Need a C# Consultant? I'm available.
Happiness in intelligent people is the rarest thing I know. -- Ernest Hemingway -
Ennis Ray Lynch, Jr. wrote:
I guess the moral is that sometimes, it is ok to not be in control.
True, but then you could also say that the moral is, if you don't want to be following a crummy set of standards, don't blow off putting them together. The nit-pick sessions are definitely useless wastes of time (enforcing the standard is good, but those pesky logic errors...), but consistent and good (and consistently good, for that matter) style and structure should make those logic errors easier to find and fix. Unfortunately, as you said, the "best and brightest" often don't want to be bothered either writing or following a standard unless it's a big one they can turn around and bash their favorite target for not following (be it MS, F/OSS, or just another team in the same office). Kind of makes you wonder just how best and bright they are, but... Standards, unfortunately, rarely just coalesce in a lot of the settings where they are most useful... so people really do need to take more interest in helping make them relevant and to stick with them. That way when it is time to do the review standards issues are quick and easy to clear up (because people are following directions in the first place) and you *can* just focus on logic (which will be easier because everyone will be familiar with where things are in the code).
Thelly wrote:
Standards, unfortunately, rarely just coalesce
That is a team issue not. The problem is most places are just sweat jobs these days with no real teamwork, leadership, or motivation. Once you have seen what I am talking about it is like an aha momemnt, why can't every place be like this? With regard to quickly finding issues, I was a TA for a programming course so I have seen some bad code but when I see a professional programmer turn his brain off and say, "I can't read this, the brackets are in the wrong place" I immediately know that I am not dealing with the top of the line and unfortunately, that is what standards documents are, an opportunity for people to dictate their preferences because they don't want to think. I once got in an argument with a "Senior Web Architect" who self-admittedly did not know any HTML (click and drag ASP.NET only) who wanted to tell me the "best" way to layout HTML and Javascript. I think that situation is systematic of all style discussions and until that changes I cannot support mandatory style unless it is for something actually important. (Ie, always checking for error return values in API calls, etc);
Need a C# Consultant? I'm available.
Happiness in intelligent people is the rarest thing I know. -- Ernest Hemingway -
I downloaded the source code to ffmpeg (written entirely in C), and was perusing the code associated with the ffplay utility. 0) The variable naming conventions they use quite frankly suck. The names they use rarely indicate what they might represent, and most of them are limited to just two letters. 1) There are almost NO comments. Well, there are so few comments as to validate the claim of "no comments", but since there are a few comments, and since programmers by their nature are a pedantic lot, "almost no comments" is technically the more correct phrasing. 2) They made widespread use of the much hated
goto. I don't know why, but I'm completely surprised at the almost complete lack of comments and the variable naming convention."Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001A lot of "professional" code is surprisingly bad. In my opinion many factors contribute to this: 1. In school, most (but not all) instructors don't place any value on code readability and maintainability; you get the grade if your code works. 2. In industry, managers usually only care if the code works. There's no incentive to write "good" code. 3. In industry, there is usually time pressure to complete projects, so the emphasis is on getting it done, and quality is sacrificed. 4. Time pressure also leaves no time for code reviews. 5. Software is a relatively recent engineering discipline, so standards haven't completely emerged. While most programmers know you should have comments, clear variable names, and avoid gotos, I'm often surprised how few programmers know the value of short functions. A function's complexity increases faster than linearly with respect to its length. If a function doubles in length, its complexity more than doubles. In my opinion, the underlying goal of all these heuristics is clarity. Clear code can be modified faster and with confidence. It's more reliable, and can be debugged faster. And that's a major difference between engineering and hacking.
-
I'm not worried about what the client thinks. I'm concerned about what maintenance programmers have to deal with.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001And those of us who get a 10 year old piece of software dropped in our lap with almost no comments appreciate your efforts! I've had an awfully frustrating time the last couple of months tracing through reams of code for hours just to figure out what is happening. One of the most common phrases to come out of my mouth is, "What on Earth were they thinking?" :omg: I'm with you, John. I hope that the legacy I leave behind for the next person is one of less frustration than I've had. :cool:
-
Hans Dietrich wrote:
"coding hall of shame" on an internal web site
That is an awesome idea.
Software Zen:
delete this;I second that. Perhaps we should have a coding hall of shame here on codeproject...