What is good code?
-
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(); }
}Naerling wrote:
I think really very few people have written good code, ever
The whole point of my question, really. :)
"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) -
this is good code according to JSOP (to save you compiling and building it, it is a flight simulator) and it works.
#include
#include
#include
#include
double L ,o ,P
,_=dt,T,Z,D=1,d,
s[999],E,h= 8,I,
J,K,w[999],M,m,O
,n[999],j=33e-3,i=
1E3,r,t, u,v ,W,S=
74.5,l=221,X=7.26,
a,B,A=32.2,c, F,H;
int N,q, C, y,p,U;
Window z; char f[52]
; GC k; main(){ Display*e=
XOpenDisplay( 0); z=RootWindow(e,0); for (XSetForeground(e,k=XCreateGC (e,z,0,0),BlackPixel(e,0))
; scanf("%lf%lf%lf",y +n,w+y, y+s)+1; y ++); XSelectInput(e,z= XCreateSimpleWindow(e,z,0,0,400,400,
0,0,WhitePixel(e,0) ),KeyPressMask); for(XMapWindow(e,z); ; T=sin(O)){ struct timeval G={ 0,dt*1e6}
; K= cos(j); N=1e4; M+= H*_; Z=D*K; F+=_*P; r=E*K; W=cos( O); m=K*W; H=K*T; O+=D*_*F/ K+d/K*E*_; B=
sin(j); a=B*T*D-E*W; XClearWindow(e,z); t=T*E+ D*B*W; j+=d*_*D-_*F*E; P=W*E*B-T*D; for (o+=(I=D*W+E
*T*B,E*d/K *B+v+B/K*F*D)*_; p K)N=1e4; else{ q=W/K *4E2+2e2; C= 2E2+4e2/ K
*D; N-1E4&& XDrawLine(e ,z,k,N ,U,q,C); N=q; U=C; } ++p; } L+=_* (X*t +P*M+m*l); T=X*X+ l*l+M *M;
XDrawString(e,z,k ,20,380,f,17); D=v/l*15; i+=(B *l-M*r -X*Z)*_; for(; XPending(e); u *=CS!=N){
XEvent z; XNextEvent(e ,&z);
++*((N=XLookupKeysym
(&z.xkey,0))-IT?
N-LT? UP-N?& E:&
J:& u: &h); --*(
DN -N? N-DT ?N==
RT?&u: & W:&h:&J
); } m=15*F/l;
c+=(I=M/ l,l*H
+I*M+a*X)*_; H
=A*_Maxxx_ wrote:
this is good code according to JSOP
You and I both know what JSOP meant. ;) ...nice plane.
"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? 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) -
John Simmons / outlaw programmer wrote:
ignoring (or ignorant of) the realities of real-world development
I don't think so. In real world development, sure a schedule may be tight and it may be necessary to write code that is not 'as good as it could be' just to get it out the door, or to fix an urgent bug. But that still isn't good code, it is just working code. If it is left as-is, and the code base is modified over time, then such code can cause more and more issues (as you must know) If you're a good, experienced, programmer, then the likelihood of quickly developed code being poor is less, but we all know we sometimes cut corners to get the job done - and we all know it comes back to bite us (or our successor) in the bum when that happens. If someone writes hundreds of lines of spaghetti code to achieve what could have been written in a few lines of well structured code, by your measure, it is good code if the output is as required. But a part of the output should be the codes longevity and maintainability, not just the function return value.
MVVM# - See how I did MVVM my way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
Quote:
But that still isn't good code, it is just working code.
Precisely said. There is a big difference between working code and good code. I am working on a project now that "works" but the code is so bad maintenance is a nightmare.
There are only 10 types of people in the world, those who understand binary and those who don't.
-
When you're on a tight schedule, if it was what it's supposed to do, it's "good" code. You guys are merely being pedantic, and are ignoring (or ignorant of) the realities of real-world development...
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"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, 1997Quote:
if it was what it's supposed to do, it's "good" code.
As said below, it is working code, not good code. There is a big difference between working code and good code and anyone who has spent enough time doing"realities of real-world development" would have known that.
There are only 10 types of people in the world, those who understand binary and those who don't.
-
John Simmons / outlaw programmer wrote:
When you're on a tight schedule, if it was what it's supposed to do, it's "good" code.
You guys are merely being pedantic, and are ignoring (or ignorant of) the realities of real-world development...well said.
"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) -
_Maxxx_ wrote:
this is good code according to JSOP
You and I both know what JSOP meant. ;) ...nice plane.
"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)Yep - I know what he meant - and he s wrong.
MVVM# - See how I did MVVM my way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
-
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)"...We obviously cannot make this determination about ourselves or our code. So who does?..." The next guy who has to maintain it, of course! That is works (or at least that you think it does) goes without saying. Kind of amazed that this discussion has been all about functionality and appearance, and not about maintainability. Anecdote#1: Worked with an arrogant jerk. After having to enhance his code, I forgave him. It was clear as a bell. Anecdote#2: Had to add a third parallel feature to some code. Boss said, no problem, should be quick because the last guy in there was supposed to make that easy - object oriented blah blah. Well, he cut & pasted the original code, changed the bits that needed to be different and forced me to rewrite his code in addition to adding mine, quadrupling the project time estimate. HIS code "worked." It just made what followed more trouble time and expense. (Oh, and made ME look bad, because although his project was "on time" mine was not!)
-
V. wrote:
but in the end, if the client is happy and the application works, it is not bad code
It may be ugly, though.
Veni, vidi, vici.
-
Yep - I know what he meant - and he s wrong.
MVVM# - See how I did MVVM my way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
_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) -
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(); }
}
