What does it mean for code to be correct, actually? The straightforward answer is "it does what the writer intended", but even that's not quite right, because I might have intended the wrong thing! For example, I might write a prime number generator while labouring under the erroneous impression that all odd numbers are prime.
It might seem obvious and not worth saying, but if incorrect code exists, and I think it does, then surely it is worth saying, because apparently someone didn't get the memo. Bertrand Meyer, Object-Oriented Software Construction If a system does not do what it is supposed to do, everything else about it-whether it is fast, has a nice user interface-matters little. And, indeed, if we're willing to give up correctness, we can presumably obtain any other attribute fairly easily.Ĭorrectness is the prime quality. Your code may have lots of other wonderful things to be said for it, but if it's not correct, they don't really matter. So here are my five rules for CRISP code in Go: they're not necessarily in order of importance, except for the first one, but it makes a nice backronym. I think good programs should be Correct, Readable, Idiomatic, Simple, and Performant. Principles are more flexible than rules, and might be more widely applicable. Over a lifetime of programming that began with a ZX81 and hasn't quite ended yet, I've found a few principles enduringly useful. A rule like "methods should only do one thing" looks great on a T-shirt, but it's not so easy to apply in practice. The problem, of course, is that few of us can agree on what "clean code" means, and how to get there. Who wants to write dirty code, unless maybe it's for a porn site? I'm sure we're all in favour of "clean code", but it's one of those motherhood-and-apple-pie things that no one can reasonably disagree with.
0 kommentar(er)
