Quality of code
-
i think those things are part of the Open Source C Style Guidelines. it's probably in the GPL. all those C libs are like that.
-
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/2001However, 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 Hemingway -
That sounds a bit exaggerated to me. Even if I reckon I have never truly looked into such a C Lib.
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 { -
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 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")
-
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 { -
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")
Graham Bradshaw wrote:
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.
Oh yeah brother! I was actually SPECIFICALLY TAUGHT to name constants "a,b,c...", increment counters "i, j, k..." and variables x,y,z... REM /*WTF??*/ SCOPE - WHAT Fri**ing SCOPE? What are you to do when the previous requirements overlap? Well it's OBVIOUOUS isn't it? [a1, b1, c1 ...etc...] lol
"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." "If Billy Barnes was worried by the prospect of a man in a bowler hat, evening suit and Wellington boots attempting a crossing of the 'Desert of No Return' inside the mind of God in order to come and get him, he was hiding it well." - Robert Rankin
-
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).