Quality of code
-
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...
-
I 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 =].You are off topic. If you don't want other's messing with your code, then don't open source it! :rolleyes: If you are releasing your source as open source, you are inviting criticism.
I've heard more said about less.
-
And 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:
Matt Totten wrote:
And 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.
I have to deal with that at work. For some reason my boss understands the code right away. Well, not me.
-
I second that. Perhaps we should have a coding hall of shame here on codeproject...
-
I like that site as well. Always good to remind yourself that you aren't as dumb as you may have thought...
-
I second that. Perhaps we should have a coding hall of shame here on codeproject...
-
Well except for the short variable names, I would consider this well written and well doccumented code.
John
John M. Drescher wrote:
Well except for the short variable names, I would consider this well written and well doccumented code.
I would tend to agree. I also think that a good find/replace of 2-char names with meaningful names would be a worthwhile effort. It's not that the code is bad or poorly documented, it's just that it could be more readable. Comments should elucidate the code, they should not be necessary to explain every piece of it, not in a language that supports at least 32 characters for each identifier.
-
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/2001John Simmons / outlaw programmer wrote:
I'm concerned about what maintenance programmers have to deal with.
I am too. Unfortunately, most programmers seem not to be. Maybe it's the attitude of "what do I care, I'll only be here for a few months or a year or so at most."
Kevin
-
A 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.
Alan Balkany wrote:
I'm often surprised how few programmers know the value of short functions.
I am too.
Kevin
-
You are off topic. If you don't want other's messing with your code, then don't open source it! :rolleyes: If you are releasing your source as open source, you are inviting criticism.
I've heard more said about less.
I wanted just to point out the fact that we are all used to get everything the easy way(tons of comments, etc). What I'm trying to say is - even if someone releses his code as open source without comments or with funny naming conventions =] he is still giving us his work for free. And the least we can do is not to jump on the creator of the code for not writing his code as we like it. As for the topic of open cource. I think it's one of the best ways to expand our knowledge. We all must keep in mind that there were programmers long before us (especially before me) and they all had the same problems and solved them. They share their knowledge with us so we can build on top of it and pushing forward. Many programmers have their own way of doing things and it's hard to get rid of the habbits ;) (I for example love to work at night. Others dont't put comments :-D ). I never had problems with shearing my code with others (and my coding technic is creazy :D ) but not once I've heard arguments like those in the first post. Buttom line - If someone gave us his code lets not point out what we think is wrong but be greatfull to him for shearing his knowledge with us. PS. I may be still of topic a little but... :)