What is the "good" program ?
-
Hi to All ! In every concrete case we can say that this program is good. But I wonder if it is possible to derive any mutual properties or creteria for the good program ? At the times of punch cards we said: If the program works from the first run - it is not a program, if it doesn't work after the third run - this is not a programmer. I tried to create the list of such mutual properties. May be somebody can expand it ? 1. It works. 2. It's code looks nice. Note: from my experience, if the program code looks bad (intuitively) - in most cases this program is wrong. 3. It's code is self-explained. Note: How - it doesn't matter: docs, comments, variables names,... 4. It has a long life. Note: I mean - it can work years and needs no or small efforts to work on new versions of environment. 5. It never fails silently. Note: Even the best program may fail. So I mean - a good program will always find chance to give you a hint. Regards, Gennady
-
Hi to All ! In every concrete case we can say that this program is good. But I wonder if it is possible to derive any mutual properties or creteria for the good program ? At the times of punch cards we said: If the program works from the first run - it is not a program, if it doesn't work after the third run - this is not a programmer. I tried to create the list of such mutual properties. May be somebody can expand it ? 1. It works. 2. It's code looks nice. Note: from my experience, if the program code looks bad (intuitively) - in most cases this program is wrong. 3. It's code is self-explained. Note: How - it doesn't matter: docs, comments, variables names,... 4. It has a long life. Note: I mean - it can work years and needs no or small efforts to work on new versions of environment. 5. It never fails silently. Note: Even the best program may fail. So I mean - a good program will always find chance to give you a hint. Regards, Gennady
Gennady Oster wrote:
3. It's code is self-explained. Note: How - it doesn't matter: docs, comments, variables names,...
Although you should always write the code itself with this at heart, I think the people who say "well written code is self documenting" are lying to themselves and people who have to maintain it in the future. No matter how good the code and relevant the variable names, code should be appropriately commented.
He who makes a beast out of himself gets rid of the pain of being a man
-
Gennady Oster wrote:
3. It's code is self-explained. Note: How - it doesn't matter: docs, comments, variables names,...
Although you should always write the code itself with this at heart, I think the people who say "well written code is self documenting" are lying to themselves and people who have to maintain it in the future. No matter how good the code and relevant the variable names, code should be appropriately commented.
He who makes a beast out of himself gets rid of the pain of being a man
Phannon wrote:
code should be appropriately commented
No doubt, but with exceptions. If the code executes the well known task (say, parameters analysis in Page_Load handler) - it may not need comments. Regards, Gennady
-
Phannon wrote:
code should be appropriately commented
No doubt, but with exceptions. If the code executes the well known task (say, parameters analysis in Page_Load handler) - it may not need comments. Regards, Gennady
-
Gennady Oster wrote:
What is the "good" program ?
A program that successfully completes its task and does no more or no less than what it has been designed for.
xacc.ide - now with TabsToSpaces support
IronScheme - 1.0 alpha 3 out nowI'd divide this on two point: n. It does what it was designed to. n+1. It does not what it was not designed to. Regards, Gennady
-
Hi to All ! In every concrete case we can say that this program is good. But I wonder if it is possible to derive any mutual properties or creteria for the good program ? At the times of punch cards we said: If the program works from the first run - it is not a program, if it doesn't work after the third run - this is not a programmer. I tried to create the list of such mutual properties. May be somebody can expand it ? 1. It works. 2. It's code looks nice. Note: from my experience, if the program code looks bad (intuitively) - in most cases this program is wrong. 3. It's code is self-explained. Note: How - it doesn't matter: docs, comments, variables names,... 4. It has a long life. Note: I mean - it can work years and needs no or small efforts to work on new versions of environment. 5. It never fails silently. Note: Even the best program may fail. So I mean - a good program will always find chance to give you a hint. Regards, Gennady
Users (and managers!) don't care about #2 and #3.
Cheers, Vikram.
The hands that help are holier than the lips that pray.
-
Users (and managers!) don't care about #2 and #3.
Cheers, Vikram.
The hands that help are holier than the lips that pray.
First - it's not right, especially concerning #3. Second - you simply write code. Will it finally look nice or not - it doesn't depend on your wish, I think. More on your talant. I don't try to create instruction - how to do good program, but rather how to evaluate the final product. Regards, Gennady
-
Hi to All ! In every concrete case we can say that this program is good. But I wonder if it is possible to derive any mutual properties or creteria for the good program ? At the times of punch cards we said: If the program works from the first run - it is not a program, if it doesn't work after the third run - this is not a programmer. I tried to create the list of such mutual properties. May be somebody can expand it ? 1. It works. 2. It's code looks nice. Note: from my experience, if the program code looks bad (intuitively) - in most cases this program is wrong. 3. It's code is self-explained. Note: How - it doesn't matter: docs, comments, variables names,... 4. It has a long life. Note: I mean - it can work years and needs no or small efforts to work on new versions of environment. 5. It never fails silently. Note: Even the best program may fail. So I mean - a good program will always find chance to give you a hint. Regards, Gennady
Code that is easy to maintain and to expand on.
"Every time Lotus Notes starts up, somewhere a puppy, a kitten, a lamb, and a baby seal are killed. Lotus Notes is a conspiracy by the forces of Satan to drive us over the brink into madness. The CRC-32 for each file in the installation includes the numbers 666." Gary Wheeler "You're an idiot." John Simmons, THE Outlaw programmer "I realised that all of my best anecdotes started with "So there we were, pissed". Pete O'Hanlon
-
Gennady Oster wrote:
5. It never fails silently. Note: Even the best program may fail. So I mean - a good program will always find chance to give you a hint.
A good point, if an app does fail it should give you a detail report on what went wrong, at least you have the chance to take the infomation to google to find a solution. Alan Cooper came up with a dialog box for error, something on the lines of...
[Dialog Box]
What went wrong
........Possible Cause
.....Possible Solution
......
[Ok] [Cancel]norm .net wrote:
Alan Cooper came up with a dialog box for error,
I really got a kick out of his satirical version of what most error messages look like to the average user: [messsage]"You have proved that you know jackshit about computers" [button 1] "Reformat My Hard Drive" [button 2] "Kill Me Now" [button 3] "I Swear to Use Pencil and Paper from Now On"
Jon Smith & Wesson: The original point and click interface
-
norm .net wrote:
Alan Cooper came up with a dialog box for error,
I really got a kick out of his satirical version of what most error messages look like to the average user: [messsage]"You have proved that you know jackshit about computers" [button 1] "Reformat My Hard Drive" [button 2] "Kill Me Now" [button 3] "I Swear to Use Pencil and Paper from Now On"
Jon Smith & Wesson: The original point and click interface
:) He had some good ideas....
-
Hi to All ! In every concrete case we can say that this program is good. But I wonder if it is possible to derive any mutual properties or creteria for the good program ? At the times of punch cards we said: If the program works from the first run - it is not a program, if it doesn't work after the third run - this is not a programmer. I tried to create the list of such mutual properties. May be somebody can expand it ? 1. It works. 2. It's code looks nice. Note: from my experience, if the program code looks bad (intuitively) - in most cases this program is wrong. 3. It's code is self-explained. Note: How - it doesn't matter: docs, comments, variables names,... 4. It has a long life. Note: I mean - it can work years and needs no or small efforts to work on new versions of environment. 5. It never fails silently. Note: Even the best program may fail. So I mean - a good program will always find chance to give you a hint. Regards, Gennady
Depends on who you ask... From the end-user's standpoint 1) Provides desired (and useful) features 2) Useful without being unattractive 3) Doesn't crash 4) Doesn't adversely affect underlying OS 5) Implements adequate help 6) Cheap (or even better, free) From the developer's standpoint 1) Clear design 2) Easily maintainable, even by new team members 3) Is completely checked in to the version control system 4) Well commented 5) Well documented 6) Still has job at end of project From management's standpoint 1) Completed on time 2) Completed at/under budget 3) Still has job at end of project From sales nazi's standpoint 1) Program sells itself 2) Can sell program for much more than it cost to produce it 3) Can use program as example of sales success when he's looking for another job
"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 -
Hi to All ! In every concrete case we can say that this program is good. But I wonder if it is possible to derive any mutual properties or creteria for the good program ? At the times of punch cards we said: If the program works from the first run - it is not a program, if it doesn't work after the third run - this is not a programmer. I tried to create the list of such mutual properties. May be somebody can expand it ? 1. It works. 2. It's code looks nice. Note: from my experience, if the program code looks bad (intuitively) - in most cases this program is wrong. 3. It's code is self-explained. Note: How - it doesn't matter: docs, comments, variables names,... 4. It has a long life. Note: I mean - it can work years and needs no or small efforts to work on new versions of environment. 5. It never fails silently. Note: Even the best program may fail. So I mean - a good program will always find chance to give you a hint. Regards, Gennady
Usually a list like this should be as short a possible. My list, rather different than yours, would be: 1. It does what the user actually wants/needs 2. It's so intuitive the user immediately understands how to use it Anything else essentially falls into those two experiences, and in fact #2 could be a considered a part of #1, but I described it separately because users often fail to realize that that is what they want, until they see the opposite. As for code looking nice and self-explanatory, those are concepts that are relative to the capabilities of the developer and subjective to what each developer considers "good" and "self-explanatory". Far too nebulous to package up into generalized statements of quality. Marc
-
Depends on who you ask... From the end-user's standpoint 1) Provides desired (and useful) features 2) Useful without being unattractive 3) Doesn't crash 4) Doesn't adversely affect underlying OS 5) Implements adequate help 6) Cheap (or even better, free) From the developer's standpoint 1) Clear design 2) Easily maintainable, even by new team members 3) Is completely checked in to the version control system 4) Well commented 5) Well documented 6) Still has job at end of project From management's standpoint 1) Completed on time 2) Completed at/under budget 3) Still has job at end of project From sales nazi's standpoint 1) Program sells itself 2) Can sell program for much more than it cost to produce it 3) Can use program as example of sales success when he's looking for another job
"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, I'm talking about program itself, not project, not user impression, not product in whole. And I unambiguously ask you. Are you a salesman :) ? Do you think that using CVS is the property of a program, not a project manager ? Regards, Gennady
-
Usually a list like this should be as short a possible. My list, rather different than yours, would be: 1. It does what the user actually wants/needs 2. It's so intuitive the user immediately understands how to use it Anything else essentially falls into those two experiences, and in fact #2 could be a considered a part of #1, but I described it separately because users often fail to realize that that is what they want, until they see the opposite. As for code looking nice and self-explanatory, those are concepts that are relative to the capabilities of the developer and subjective to what each developer considers "good" and "self-explanatory". Far too nebulous to package up into generalized statements of quality. Marc
Marc, You're on the user standpoint. I'm asking you as a developer. I'm sure that the programming is much closer to art than to handycraft. So, the definite level of uncertainty or taste-dependency exists. And you say:
Marc Clifton wrote:
concepts that are relative to the capabilities of the developer
This is exactly what I try to evaluate. Regards, Gennady
-
John, I'm talking about program itself, not project, not user impression, not product in whole. And I unambiguously ask you. Are you a salesman :) ? Do you think that using CVS is the property of a program, not a project manager ? Regards, Gennady
Gennady Oster wrote:
I'm talking about program itself, not project, not user impression, not product in whole.
And I say again, from who's viewpoint?
Gennady Oster wrote:
And I unambiguously ask you. Are you a salesman [Smile] ?
No, I'm a programmer. My view of what makes a program "good" is compeltely different from my wife's view as merely the end user.
Gennady Oster wrote:
Do you think that using CVS is the property of a program, not a project manager ?
If the program is checked in, and can be checked out and compiled without any problems, then yeah, it's a step closer to a good program. Despite our (programmers) desire for everything to be black and white, on or off, or 1 or 0, real life dictates otherwise. The sooner a lot more programmers realize that, the sooner they start writing better programs.
"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 -
Marc, You're on the user standpoint. I'm asking you as a developer. I'm sure that the programming is much closer to art than to handycraft. So, the definite level of uncertainty or taste-dependency exists. And you say:
Marc Clifton wrote:
concepts that are relative to the capabilities of the developer
This is exactly what I try to evaluate. Regards, Gennady
Gennady Oster wrote:
I'm asking you as a developer.
Where did you mention that "as a developer", what makes a program "good"? We're programmers. If the problem has been posed, and there are insufficient requirements with which to establish an opinion, we start asking questions and/or providing solutions based on several probabilities.
Gennady Oster wrote:
I'm sure that the programming is much closer to art than to handycraft.
Wrong. We're not really programmers anymore - we're integrators. Programming USED to be an art back when you only had 4k of RAM to work with, and when you were hobbled by writing TSR programs that consumed as little memory as possible and found a way to use memory above 640K, or when you were writing Turbo Pascal apps that made judicious use of overlays. THAT was art. Today's programming isn't nearly as fun or "artful".
"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 -
Gennady Oster wrote:
I'm talking about program itself, not project, not user impression, not product in whole.
And I say again, from who's viewpoint?
Gennady Oster wrote:
And I unambiguously ask you. Are you a salesman [Smile] ?
No, I'm a programmer. My view of what makes a program "good" is compeltely different from my wife's view as merely the end user.
Gennady Oster wrote:
Do you think that using CVS is the property of a program, not a project manager ?
If the program is checked in, and can be checked out and compiled without any problems, then yeah, it's a step closer to a good program. Despite our (programmers) desire for everything to be black and white, on or off, or 1 or 0, real life dictates otherwise. The sooner a lot more programmers realize that, the sooner they start writing better programs.
"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:
And I say again, from who's viewpoint?
We're on the developers site (I hope). We're both developers (I think). These are the conditions. Now the question: Who's opinion I'm interested in ? I don't intend to write the new version of "The Mythical Man-Month...", I asked programmers about program. I know that my English is poor, but I hoped that it is at least clear :) . Regards, Gennady
-
Gennady Oster wrote:
I'm asking you as a developer.
Where did you mention that "as a developer", what makes a program "good"? We're programmers. If the problem has been posed, and there are insufficient requirements with which to establish an opinion, we start asking questions and/or providing solutions based on several probabilities.
Gennady Oster wrote:
I'm sure that the programming is much closer to art than to handycraft.
Wrong. We're not really programmers anymore - we're integrators. Programming USED to be an art back when you only had 4k of RAM to work with, and when you were hobbled by writing TSR programs that consumed as little memory as possible and found a way to use memory above 640K, or when you were writing Turbo Pascal apps that made judicious use of overlays. THAT was art. Today's programming isn't nearly as fun or "artful".
"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:
Wrong. We're not really programmers anymore
If so - what's wrong in my words?. Programming is the art, but we're now not programmers. Almost agree. But ... I'm less pessimistic, although I also feel nostalgia about the times when Germain's "IBM/360" was our Bible. There is need in programmers, programming yet exists, and this site is acually the proof. Somebody have to create the "Lego" and it's framework. But I can also understand you. When you see children that construct from "Lego" something that they call "program" and therefore call themselves "programmers" - this may get mad anybody :zzz: . Regards, Gennady
