What is good code?
-
public int Add(int num1, int num2)
{
return num1 + num2;
}public int Add(int num1, int num2)
{
return num1 + num2 - 0;
}Both code will work as it designed for. But which one is the best code?
-
Actually it can. Just because something is working, right here, right now does not mean that it's good code. It simply means that it was adequate in the moment. People leave, move to different positions etc... so the chances are high that someone else will have to follow along and attempt to update or add to your code. If they can't figure it out, or unknowingly spawn bugs because it's so difficult to follow the horrible mess you left then I don't think that fits what one would call good code. When there are pressing business reasons driving those changes or additions, that "good code" suddenly looks much less "good". Even changing your own code, if you don't design it well it's very easy to get caught with your pants down when unexpected requests make you realize that you need to rewrite a large part of an application. This also seems to be one of the harder concepts to communicate to business people, the need for time to structure seemingly simple things properly. Sweat more now, bleed less later and all that. Still, sometimes you just have to hack it up and get something working, but it shouldn't be the default approach.
-
V. wrote:
good code is code that works
I like where you are going with this. One of the reasons why I posted the question. I was up last night thinking about this after reading about someone who thinks they know what good code is.
"the meat from that butcher is just the dogs danglies, absolutely amazing cuts of beef." - DaveAuld (2011)
"No, that is just the earthly manifestation of the Great God Retardon." - Nagy Vilmos (2011) "It is the celestial scrotum of good luck!" - Nagy Vilmos (2011) "But you probably have the smoothest scrotum of any grown man" - Pete O'Hanlon (2012)"good code is code that works " NO! This is a mistake many managers make, who can't tell their good programmers from their bad programmers. Bad code will APPEAR TO work, so this heuristic doesn't tell you much. Way more time and money are spent on code maintenance than development, so MAINTAINABLE code is good code. Bad code is difficult to maintain. It's hard to figure out how it works, and modifications have a high probability of breaking the code is some remote location. But it will appear to work. The defects in bad code are as invisible as a limp in a sitting man. Good code is CLEAR. Many factors influence clarity. Good code rarely has long methods, which reduces complexity since a method's complexity increases faster than linear as the length grows. Minimizing dependencies on code in distant locations is also a factor in clear code. Simple code is clear. Good code also has sufficient comments to quickly figure out how it works. For good code, strive for clarity.
"Microsoft -- Adding unnecessary complexity to your work since 1987!"
-
Who determines if your code is good? What is good code and what are the precise criteria for giving it a status of "good"? Since most of your code will never be reviewed by your peers (outside of work) then how do you know it is worth a damn, really? If I think your code sucks but the next guy thinks it is good, then who is right? This kind of goes in line with my other thoughts about the "greatness" of an individual programmer. Who determines that a person is a great programmer and that person writes some damn good code? You? Me? None of the above? We obviously cannot make this determination about ourselves or our code. So who does?
"the meat from that butcher is just the dogs danglies, absolutely amazing cuts of beef." - DaveAuld (2011)
"No, that is just the earthly manifestation of the Great God Retardon." - Nagy Vilmos (2011) "It is the celestial scrotum of good luck!" - Nagy Vilmos (2011) "But you probably have the smoothest scrotum of any grown man" - Pete O'Hanlon (2012)Einstein said it best: Everything should be made as simple as possible, but not simpler. Good code to me are: 1. Loose coupling and high cohesion. 2. Use best practice like patterns, don't re-invent the wheel. 3. Use appropriate algorithm for the task. 4. Try to stay within standard libraries if at all possible. 5. Be persistent on coding pattern and comments. Make it as if you are writing something for the next person who know nothing about your program to understand and easily followed your thought process.
-
Reread your code next week, if you still understand what is going on it has potential to be good. Reread your code next month, if you still understand what is going on your code might be pretty allright. Reread your code after six months, if you still understand what is going on you probably have a winner. Reread your code after a year, if you still understand what is going on your code is good. Now have a colleague read your code. If he can't understand it he is in desperate need for some schooling (after all, your code is good). Now have your boss read your code. If he can't understand it your code wasn't good after all (even if your boss isn't a programmer, he makes the rules). Now have someone outside of your company read it. If he can't understand it who cares? His opinion doesn't matter anyway. Code that gets older than approximately five years (perhaps probably less) is bad code by definition. I think really very few people have written good code, ever :)
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
} -
Who determines if your code is good? What is good code and what are the precise criteria for giving it a status of "good"? Since most of your code will never be reviewed by your peers (outside of work) then how do you know it is worth a damn, really? If I think your code sucks but the next guy thinks it is good, then who is right? This kind of goes in line with my other thoughts about the "greatness" of an individual programmer. Who determines that a person is a great programmer and that person writes some damn good code? You? Me? None of the above? We obviously cannot make this determination about ourselves or our code. So who does?
"the meat from that butcher is just the dogs danglies, absolutely amazing cuts of beef." - DaveAuld (2011)
"No, that is just the earthly manifestation of the Great God Retardon." - Nagy Vilmos (2011) "It is the celestial scrotum of good luck!" - Nagy Vilmos (2011) "But you probably have the smoothest scrotum of any grown man" - Pete O'Hanlon (2012)First off, good code is code that pleases the guy who pays you for it. If the customer wants code yesterday, and doesn't care if it has errors, then that's what determines good. If you spend a month writing optimized, bug-free, carefully documented code, you fail. The customer determines whether security, correctness, reusability, readability are important. Sometimes, the customer makes stupid choices, but it's their right to pay for what they want, and your job to give that to them. It happens that many customers want "good" code, and don't put unreasonable constraints on how long you have to write it. Then you have to judge "good". For many people, "good" means "as good as I know how to do". That, in turn, is a function of seat time. Very experienced programmers know more about what makes code good, so another answer probably more appropriate to the discussion is "A very experienced developer who is a respected member of your team should say if your code is good." Good is still situational, depending on the way the code is to be used, but now you are responsible to map the requirements to the code. In the absense of external requirements and constraints, there is only "beautiful" code. Beautiful code is like art, you may not be able to define it, but you know what you like. It tends to be code with a high score for all attributes you can think of; readable, maintainable, minimal, optimal, secure, etc. Even inexperienced developers can usually identify beautiful code when they see it. Experienced devs are more likely to appreciate beautiful code, because they recognize more aspects of it.
-
_Maxxx_ wrote:
and he s wrong.
your opinion. Many great programmers responded to my question, all with different ideas and answers. Many of them share the same view as John. Are they wrong as well? One of the points of my question was, who determines good code? Which person's determination is really correct. You have an opinion but your opinion is not fact.
"the meat from that butcher is just the dogs danglies, absolutely amazing cuts of beef." - DaveAuld (2011)
"No, that is just the earthly manifestation of the Great God Retardon." - Nagy Vilmos (2011) "It is the celestial scrotum of good luck!" - Nagy Vilmos (2011) "But you probably have the smoothest scrotum of any grown man" - Pete O'Hanlon (2012)If you have worked in a team of say 20+ developers on full life cycle projects, you probably wouldn't asked that question. :doh: When your code holds up the next release milestone waiting to be reviewed and bring up to the team's standard (code style, algorithms, maintainability, etc.) On the other hand, if your code reviewed by no one and you maintain your own code, then all working code you write are good.
-
"good code is code that works " NO! This is a mistake many managers make, who can't tell their good programmers from their bad programmers. Bad code will APPEAR TO work, so this heuristic doesn't tell you much. Way more time and money are spent on code maintenance than development, so MAINTAINABLE code is good code. Bad code is difficult to maintain. It's hard to figure out how it works, and modifications have a high probability of breaking the code is some remote location. But it will appear to work. The defects in bad code are as invisible as a limp in a sitting man. Good code is CLEAR. Many factors influence clarity. Good code rarely has long methods, which reduces complexity since a method's complexity increases faster than linear as the length grows. Minimizing dependencies on code in distant locations is also a factor in clear code. Simple code is clear. Good code also has sufficient comments to quickly figure out how it works. For good code, strive for clarity.
"Microsoft -- Adding unnecessary complexity to your work since 1987!"
-
>> Code that gets older than approximately five years (perhaps probably less) is bad code by definition. On the contrary, bad code got rewritten more often. Good code usually long lives.
Leng Vang wrote:
On the contrary, bad code that doesn't do what it's supposed to do got rewritten more often. Good code that works usually long lives.
Code that works isn't always good code :)
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
} -
Who determines if your code is good? What is good code and what are the precise criteria for giving it a status of "good"? Since most of your code will never be reviewed by your peers (outside of work) then how do you know it is worth a damn, really? If I think your code sucks but the next guy thinks it is good, then who is right? This kind of goes in line with my other thoughts about the "greatness" of an individual programmer. Who determines that a person is a great programmer and that person writes some damn good code? You? Me? None of the above? We obviously cannot make this determination about ourselves or our code. So who does?
"the meat from that butcher is just the dogs danglies, absolutely amazing cuts of beef." - DaveAuld (2011)
"No, that is just the earthly manifestation of the Great God Retardon." - Nagy Vilmos (2011) "It is the celestial scrotum of good luck!" - Nagy Vilmos (2011) "But you probably have the smoothest scrotum of any grown man" - Pete O'Hanlon (2012)> Who determines if your code is good? Well, if you are a solo developer, then you are the one until your company or client fires you for incompetence. > Since most of your code will never be reviewed by your peers (outside of work) then how do you know it is worth a damn, really? Depends your client (which includes the company employing you). Your code is only as good as your desire to maintain earning an income. But you say: Since most of your code will never be reviewed... Another way to say it: "Who's ever gonna find out yer programming crappy code?" A deceptive programmer simply won't give a damned. I could have a sign that reads "Crime-Free Zone" and use chalk to draw a 10-foot radial circle around me, but this won't stop a criminal. Same goes for a deceptive programmer. A car driver in the U.S. is required by law to have car insurance. 85% of drivers do have this insurance. 15% don't. Those who do have car insurance mostly (99% or more, perhaps) DON'T purpose to go out of their way to USE that car insurance (that is, they're not driving around looking to cause an accident). Thus, yes, the "who" is significant. When the "who" (i.e., programmer) seeks to use "programmer insurance", because it is "virtual" (e.g., just code!), they CAN and SHOULD go OUT OF THEIR WAY to use that "programmer insurance". What are some of the available programmer insurance offerings? Certifications, classes, getting involved with public/open-source projects (e.g., CodeProject), control version software (CVS), and code analysis software are a few ideas that come to mind. I do not have stats as to how many programmers use "programmer insurance". CodeProject could do a weekly vote thingy like they do, but the same programmers who go out of their way to not use "programmer insurance" may try (and most likely will continue) to deceive and say they do use such. For the record: every bit of this posting is AND isn't true. After all, being the programmers that we are, we'll "compile" it in our minds per the static headers we have and/or hack it or build our own header files!!
Thus, I'm glad I, just like everyone else, did (not) answer your questions...
:wtf:
The best way to improve Windows is run it on a Mac. The best way to bring a Mac to its knees is to run Windows on it. ~ my brother Jeff
-
The good code in my opinion is one that regardless of whether the developer is junior or senior it will look and understand more easily.
Sorry for my english is bad. I used the google translator.
Transcription #1: Good code, in my opinion, is code that, regardless of whether a person is a junior or senior developer, will function as needed (including compiling and reasonable execution efficiency) and is easy to read/understand. Transcription #2: The spaghetti sauce is gonna be all over your and everyone else's face and clothing when you slurp up the noodles like a dumb animal! ;P (for our non-English, non-American readers, go to youtube.com and search for "slurp spaghetti noodle" ...)
The best way to improve Windows is run it on a Mac. The best way to bring a Mac to its knees is to run Windows on it. ~ my brother Jeff
-
Slacker007 wrote:
What is good code
Code written by me and no one else, of course. You can have endless discussions, but IMHO good code is code that works (does the required job).
V.
It also helps if the code is readable and maintainable.
-
_Maxxx_ wrote:
and he s wrong.
your opinion. Many great programmers responded to my question, all with different ideas and answers. Many of them share the same view as John. Are they wrong as well? One of the points of my question was, who determines good code? Which person's determination is really correct. You have an opinion but your opinion is not fact.
"the meat from that butcher is just the dogs danglies, absolutely amazing cuts of beef." - DaveAuld (2011)
"No, that is just the earthly manifestation of the Great God Retardon." - Nagy Vilmos (2011) "It is the celestial scrotum of good luck!" - Nagy Vilmos (2011) "But you probably have the smoothest scrotum of any grown man" - Pete O'Hanlon (2012)Slacker007 wrote:
your opinion.
Of course? If there was a genuine IEEE standard for Good Code then I'd have pointed everyone at it.
Slacker007 wrote:
Many great programmers responded to my question
Hmm? What makes a great programmer - need to ask that question too!
Slacker007 wrote:
Are they wrong as well?
Yes
Slacker007 wrote:
You have an opinion but your opinion is not fact.
well, I would argue that using the fact that it works as a sole criterion for "good" code is demonstrably wrong. I believe I could show John and any of the other "great" programmers out there some really bad code that performs the function intended - and that they would agree that it is not good code. There are some examples here[^] QED
MVVM# - See how I did MVVM my way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
-
"good code is code that works " NO! This is a mistake many managers make, who can't tell their good programmers from their bad programmers. Bad code will APPEAR TO work, so this heuristic doesn't tell you much. Way more time and money are spent on code maintenance than development, so MAINTAINABLE code is good code. Bad code is difficult to maintain. It's hard to figure out how it works, and modifications have a high probability of breaking the code is some remote location. But it will appear to work. The defects in bad code are as invisible as a limp in a sitting man. Good code is CLEAR. Many factors influence clarity. Good code rarely has long methods, which reduces complexity since a method's complexity increases faster than linear as the length grows. Minimizing dependencies on code in distant locations is also a factor in clear code. Simple code is clear. Good code also has sufficient comments to quickly figure out how it works. For good code, strive for clarity.
"Microsoft -- Adding unnecessary complexity to your work since 1987!"
What's also helpful is: if the methods/functions are strongly focused in what they do (more of a single-mindedness)--Cohesion and if the dependency of coupling of the modules is low Watch out for cyclic dependencies, where two or more modules call into each other. Without cyclic dependencies, you can level your functions and objects much easier.
-
Your question and assertion seem to be based around the fact that good code is not knowable. This is much like the philosophical argument that right and wrong are subjective and any objective determination cannot be made. I largely agree with those concepts, however I also question the necessity of finding objective determinations of what is good/right/wrong/etc. Such an answer really only has relevance among sentient beings such as humans. The quality of code especially so (not too many platypodes care about the style of brackets you use). And code quality will be relevant to certain humans more than others. There are many dimensions to relevance you could use to judge code quality. For one, a customer probably cares most about how well the code functions (e.g., that it is bug free). However, customers can be pretty ignorant, so they may be unable to judge that code is future-proof, which saves them money (even if they are unaware of it). Then there is your boss. He might care most about getting things done in a timely manner. From his perspective, getting things done fast makes you a quality coder, but whether that means your code is good or not depends on the perspective. From your collegue who was educated with 3 PhD's, maybe your code doesn't look as pristine as she'd like. However, your practical nature might conclude that pristine code is a waste of time, or you might have a different idea of what pristine code looks like. Much like morality, judgement of good or bad depends on the perspective, and that perspective can vary depending on how you want to select a group. You may be right that there is no objective measure of good code. However, that does not mean that, say, the .Net community does not have a few guidelines. And I'd also add that the larger your group is from which you are considering a perspective, the more generic you can be in declaring rules for quality. There may be some absolutes from the widest perspective (all humans), but by that time they may be so generic as to be useless to you on a specific level. So I guess this is really a bigger discussion. One that probably wouldn't be resolved any sooner than the "right" philosophy is achieved. :)
Good code is relative. Of course there are common criteria to us all for what is considered to be good code, but that goes with anything in life. I read this article by a guy who had the audacity to say he knew what good code was. The way the article was written bothered me enough to post a question here regarding "what is good code". Go back through all 98 replies to my question. Which answers come up the most? This is what makes good code, in my "opinion"; a collective answer versus an individual answer. I know I give you a hard time, but I have always, and continue, to value your opinions. ;) -- cheers.
"the meat from that butcher is just the dogs danglies, absolutely amazing cuts of beef." - DaveAuld (2011)
"No, that is just the earthly manifestation of the Great God Retardon." - Nagy Vilmos (2011) "It is the celestial scrotum of good luck!" - Nagy Vilmos (2011) "But you probably have the smoothest scrotum of any grown man" - Pete O'Hanlon (2012) -
"good code is code that works " NO! This is a mistake many managers make, who can't tell their good programmers from their bad programmers. Bad code will APPEAR TO work, so this heuristic doesn't tell you much. Way more time and money are spent on code maintenance than development, so MAINTAINABLE code is good code. Bad code is difficult to maintain. It's hard to figure out how it works, and modifications have a high probability of breaking the code is some remote location. But it will appear to work. The defects in bad code are as invisible as a limp in a sitting man. Good code is CLEAR. Many factors influence clarity. Good code rarely has long methods, which reduces complexity since a method's complexity increases faster than linear as the length grows. Minimizing dependencies on code in distant locations is also a factor in clear code. Simple code is clear. Good code also has sufficient comments to quickly figure out how it works. For good code, strive for clarity.
"Microsoft -- Adding unnecessary complexity to your work since 1987!"
I'll make a point of saying "I do not disagree with your statement", because clarity is a *very* important part of what I believe defines good code. But I will also point out that good code is, indeed, code that works. This may seem obvious, but having maintainable code that doesn't do the job is of little use; it simply means fixing it is unlikely to take as long as fixing broken spaghetti code. The notion of what makes good code generally falls under the purview of software engineering, à la Gang of Four design patterns and the like. I don't think anyone here has given an incorrect opinion, as all are valid measures of good code; meaningful variable names, concise functions with well-written comments/documentation and low-cohesion to aid maintainability and extensibility are just a few measures of code quality.
Sometimes a fist in the face says more than a thousand honeyed words.
-
Slacker007 wrote:
Who determines if your code is good?
Myself, hence my code is bad.
Slacker007 wrote:
What is good code and what are the precise criteria for giving it a status of "good"? Since most of your code will never be reviewed by your peers (outside of work) then how do you know it is worth a damn, really?
If I think your code sucks but the next guy thinks it is good, then who is right?There's no precise criteria. It is hard to recognize good code (and it is also matter of personal taste). On the other hand bad code is pretty recognizable at a glance.
Slacker007 wrote:
This kind of goes in line with my other thoughts about the "greatness" of an individual programmer. Who determines that a person is a great programmer and that person writes some damn good code? You? Me? None of the above?
Myself? :-D Great programmers are like great artists. You may say they are great with some confidence. For instance we may argue on a particular Picasso's painting. But no one will doubt about Picasso greatness (well, the dumb will do, but that's a point in favour).
Veni, vidi, vici.
CPallini wrote:
On the other hand bad code is pretty recognizable at a glance.
Oh, if only that were true. 15 seconds after I first saw "if ((Max-Thread_Count_Allowed + Thread_Count_Increment) <= Current_Thread_Count) Get_New_Threads();" I knew that was bad code. It took me a week to convince my managers there was a problem with that logic. (So, how long did it take for you to spot the bug?) If anything, it certainly makes a good case for using self documenting variable names. That was the good part of the code.
-
V. wrote:
good code is code that works
I like where you are going with this. One of the reasons why I posted the question. I was up last night thinking about this after reading about someone who thinks they know what good code is.
"the meat from that butcher is just the dogs danglies, absolutely amazing cuts of beef." - DaveAuld (2011)
"No, that is just the earthly manifestation of the Great God Retardon." - Nagy Vilmos (2011) "It is the celestial scrotum of good luck!" - Nagy Vilmos (2011) "But you probably have the smoothest scrotum of any grown man" - Pete O'Hanlon (2012) -
CPallini wrote:
On the other hand bad code is pretty recognizable at a glance.
Oh, if only that were true. 15 seconds after I first saw "if ((Max-Thread_Count_Allowed + Thread_Count_Increment) <= Current_Thread_Count) Get_New_Threads();" I knew that was bad code. It took me a week to convince my managers there was a problem with that logic. (So, how long did it take for you to spot the bug?) If anything, it certainly makes a good case for using self documenting variable names. That was the good part of the code.
I was NOT talking about buggy code, about ugly code instead. Your sample code, however, you should (probably) be something like
if ( Current_Thread_Count + Thread_Count_Increment <= Maximum_Thread_Count)
Get_New_Threads();I used
Maximum_Thread_Countbeacuse is not very clear the meaning of bothMaxandThread_Count_Allowed.Veni, vidi, vici.
