Quality of 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 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'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
-
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 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 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;