Linked by Thom Holwerda on Fri 15th Feb 2013 10:40 UTC
General Development "Since I left my job at Amazon I have spent a lot of time reading great source code. Having exhausted the insanely good idSoftware pool, the next thing to read was one of the greatest game of all time: Duke Nukem 3D and the engine powering it named 'Build'. It turned out to be a difficult experience: The engine delivered great value and ranked high in terms of speed, stability and memory consumption but my enthousiasm met a source code controversial in terms of organization, best practices and comments/documentation. This reading session taught me a lot about code legacy and what helps a software live long." Hail to the king, baby.
Thread beginning with comment 552819
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[5]: Comment by ilovebeer
by Alfman on Mon 18th Feb 2013 16:05 UTC in reply to "RE[4]: Comment by ilovebeer"
Alfman
Member since:
2011-01-28

ilovebeer,

"You can't get around the fact that if the software works it has been engineered correctly because it's doing what it was designed to do."

It works...until it doesn't.

As long as it's limited to personal code, and the original developer doesn't care about how it's engineered, then maybe it doesn't matter to him. But if he's working in a corporate setting, some other poor sole will inherit that code and he'll be none-to-pleased to learn that the earlier developer completely disregarded code quality in his work.


"Also, your idea of what is 'well-written and structured' can be and is very different from what other people deem as the same. One huge thing you seem to be missing is that personal opinion plays a large role in making judgments about someones code. I know several great coders who are often times in disagreement about code-related issues."

Of course there are different opinions, especially with details that come down to different tastes. But ask them if they think the engineering doesn't matter at all as long as the end product works. The good software engineers I know are proud of good engineering.

Reply Parent Score: 3

RE[6]: Comment by ilovebeer
by ilovebeer on Mon 18th Feb 2013 20:45 in reply to "RE[5]: Comment by ilovebeer"
ilovebeer Member since:
2011-08-08

"You can't get around the fact that if the software works it has been engineered correctly because it's doing what it was designed to do."

It works...until it doesn't.

Or, .... it works fine without a single problem until the software is no longer needed.

As long as it's limited to personal code, and the original developer doesn't care about how it's engineered, then maybe it doesn't matter to him. But if he's working in a corporate setting, some other poor sole will inherit that code and he'll be none-to-pleased to learn that the earlier developer completely disregarded code quality in his work.

Or, ... regardless of the personal or corporate environment, somebody else assumes responsibility of maintaining it and has no problem understanding or adapting to the previous coders "quality" and coding style.

Or, ... the code, regardless of environment is easily maintained because its duties simple and how "beautiful" or "crap" is in someones opinion is irrelevant.

Or, ... the code doesn't even need to be maintained.

Of course there are different opinions, especially with details that come down to different tastes. But ask them if they think the engineering doesn't matter at all as long as the end product works. The good software engineers I know are proud of good engineering.

I never said engineering doesn't matter at all. I said if the software works as intended and is stable, it has been engineered correctly thus implying the engineering does in fact matter.

Since you guys seems to completely disagree with me, what is the exact deciding factor as to whether or not code is "good"? What is the exact deciding factor as to whether or not the engineering is "good".

I am saying code quality is not black & white and you agree that the judgment of code is often a matter of opinion, yet you insist code is either good or bad. You can't have it both ways, either there is grey or it is black & white only.

What "you" deem as crap code may be perfectly stable and function without any issue for as long as needed. That begs to ask, if that is true, how can the code actually be crap? Such cases are just as much in the realm of possibility as anyone in disagreement with me has suggested.

Being handed someone elses code to work with can be a nightmare, or it can be a piece of cake or non-issue. Neither the former nor the latter is more true than the other.

I will say it again, ... Judgments about the quality of someones code must be made on a case-by-case basis and you have to consider more than just you own personal opinion and preference. Remember, I said if it works, it works and there's no getting around it.. I did not say if it work but has problems, it works.

Reply Parent Score: 2

RE[7]: Comment by ilovebeer
by Alfman on Tue 19th Feb 2013 06:05 in reply to "RE[6]: Comment by ilovebeer"
Alfman Member since:
2011-01-28

ilovebeer,

"I am saying code quality is not black & white and you agree that the judgment of code is often a matter of opinion, yet you insist code is either good or bad. You can't have it both ways, either there is grey or it is black & white only."

Who said it's black and white? It's full of greys. You should visualize it as a multidimensional venn diagram that often contains many good solutions (as well as some that are on the fence or just plain bad). There's always a certain degree of subjectivity, but you are trying to extend this subjectivity well beyond what is reasonable in order to rationalize bad code.



"I never said engineering doesn't matter at all. I said if the software works as intended and is stable, it has been engineered correctly thus implying the engineering does in fact matter."

"...Remember, I said if it works, it works and there's no getting around it.. I did not say if it work but has problems, it works."


It's a fallacy to treat all code as being identical in quality even though it works. Here's a trivial example using a multiplication function, but imagine that it's thousands of lines of complex production code instead.

int A(int a, int b) {
return a*b;
}

int B(int a, int b) {
int r=0;
for(;a>0;a--) r+=b;
for(;a<0;a++) r-=b;
return r;
}

int C(int a, int b) {
if (a==0) return 0;
if (a<0) return -C(-a,b);
int* m=malloc(a*sizeof(int));
for(int i=0; i<a; i++) m[i] = b;
for(int i=0; i<a-1; i++) m[i+1] += m[i];
return m[a-1];
}

etc...

Hopefully this convinces you that just because something happens to work, it doesn't make it good code. Common attributes of bad code are lack of clarity, unnecessary complexity, insane difficulty to maintain, latent bugs which might not show up for years, etc. When good developers are faced with bad code, we're often tempted to rewrite the whole damn thing, but nature of our jobs sometimes means we have to 'fix' the bad code instead. This will technically work, but it still remains bad code. Fixing the memory leak in function C obviously won't make it good code.

Reply Parent Score: 2