Rules for Good Code

4 points by c-rack 10 years ago | 4 comments

ketralnis 10 years ago |

This may suit the author's style and that's great. But I strongly disagree with several of these. Calling them "rules for good code" just seems like a lot of hubris.

> 0. Use Git and Github. I'm not going to dignify this with a non-zero number. If you aren't using git and github.com then you are already making excuses for doing it wrong

Okay? I'm glad you found a tool that works for you, but there are plenty of others. And he's not saying "use source control". He's literally saying that no other tool is good enough.

> 2. Make it Open Source

I don't wanna. Doesn't make my code bad.

> 3. Always Be Making APIs

This is extremely web centric. For web specifically there's a case to be made here, but he certainly didn't make it

> 4. Don't Document the Code

I guess don't ever work on a team of more than two then.

> 6. Better is the Enemy of the Good [...] Do not optimize your code. Aim for "OK" and then stop

That may work for your project, and maybe every project you've worked on. But it won't work for an airplane's safety systems.

> 9. Make Portable Code [...] Your code should run on every box there is

Why? Everything else he's talking about is very web-centric, so let's assume that. Don't you control your whole stack from metal to OS then? Why bother making it super portable when you know everything about the system that will be running the code? You have all of the same upsides of programming for a game console. You're in one of the few environments where you can use all of your platform's features. Use them!

> 10. Lie to Your Management [...] When they demand schedules, plannings, designs, and architectures, lie to them

I don't even know where to start here.

jestar_jokin 10 years ago | |

Yes, this is a terrible list. Part of it is the delivery. Most points need more explanation than just "because I say so". If your point is to educate, then don't use aggressive language like "you are already making excuses for doing it wrong"; otherwise, you're just saying "you're doing it wrong, dummy", which by itself is nonconstructive.

dragonwriter 10 years ago | |

> > 3. Always Be Making APIs

> This is extremely web centric.

I don't think it is -- in fact, I think its one of the few things on the list that makes a good general rule; most of any project is defining APIs, even if they are initially used only internally by that project. The readability and comprehensibility of the code in that project -- and its maintainability -- will be enhanced if that is recognized, and the same principles of API design that would be applied to public APIs are applied in general to these internal APIs. (It'll also make it easier to reuse the code later if you recognize an application in an unrelated project, but while that's an important benefit, its secondary.)

ry_ry 10 years ago |

"0. Use Git and Github

I'm not going to dignify this with a non-zero number. If you aren't using git and github.com then you are already making excuses for doing it wrong. It is not about fashion or groupthink. Github (the company) know how to make Good Code, and their tools reflect this."

I stopped reading there, and shed a single tear for all the enormously talented people through history who thought they had made anything even remotely worthwhile pre-github.

:,(

Github is great, but it's not a prerequisite of Good Code for crying out loud. This article is not Good Writing.