Earlier quoted context omitted.
Where 65 means ‘A’? Madness.
A is 65 in ASCII. http://www.asciitable.com
I know. It was a joke.
The Design of Software is a Thing Apart
41–50 of 124 posts
Re: The Design of Software is a Thing Apart
#42Earlier quoted context omitted.
> ASCII_A could be set incorrectly, or have a dumb type, and is more verbose anyway. By using the character directly, the code speaks its purpose. I disagree. ASCII_A speaks it's purpose (we purposefully want an ASCII A stored here). And one can check the constant's definition, and immediately tell if it's correct. E.g. const ASCII_A = 'A' // correct const ASCII_A = 'E' // wrong So: return x >= ASCII_A tell us the in…
return x >= "A"; // ascii A Gets the whole message across in one line, as does using 65 with the comment.
Comments aren't so good - now you have 2 things to change when the program changes. In the real world, often the comment won't be updated and will become actively misleading/wrong/bad.
Re: The Design of Software is a Thing Apart
#43> Those who speak of “self-documenting code” are missing something big: the purpose of documentation is not just to describe how the system works today, but also how it will work in the future and across many versions. And so it’s equally important what’s not documented. Documentation also (can) tell you why the code is a certain way. The code itself can only answer "what" and "how" questions. The simplest case to sh…
> Some might claim unit tests will solve this Yes. Tests will solve this. Your point is perfect for tests. If another experienced coder cannot comprehend from the tests why something is wrong, then improve the tests. Use any mix of literate programming, semantic names, domain driven design, test doubles, custom matchers, dependency injections, and the like. If you can point to a specific example of your statement, i.…
Here I'd distinguish between system/integration and unit tests. Unit tests as a whole tend to amount to a mirror of the code base. If a given function f returns '17' and a test validates that fact, all we've done is double check our work -- which has some value, but doesn't protect against the case in which f is _supposed_ to return 18 and both the code and the test are wrong.
OTOH, system tests provide a realm where external implicit/explicit requirements may actually be validated. Perhaps.
Re: The Design of Software is a Thing Apart
#44return x >= ‘A’; Would be better than return x >= ASCII_A; surely. ASCII_A could be set incorrectly, or have a dumb type, and is more verbose anyway. By using the character directly, the code speaks its purpose.
In this strawman example, perhaps. However, code is usually surrounded by other code. So you could have the 'A' in multiple places. By using an explicit identifier you are protecting yourself against typos (depending on the language, it could be a compile-time error or at worst a very clear runtime error instead of a logic error). The other benefit of ASCII_A is that you are signalling that you are doing ASCII compar…
> In this strawman example, perhaps.
I'm not so sure it's a straw man, I often see defining constants like this cargo culted even if there are only one or two uses. In that case 'A' is great because it's value is right there, I don't have to look at the assignment and then go look up what the actual value is, so it's more readable.
When it's used in several disparate places then ASCII_A is better and your arguments about correctness should take precedence, we sacrifice some readability but it's worth it.
Re: The Design of Software is a Thing Apart
#45This is a lovely article. Software is a possibly a) errant and b) misinterpreted operational semantics of some other semantic horizons of contractual or implicit expectations. Knuth's Literate Programming was onto something. We inhabit a world of word problems and even faulty realizations of rarer formal specifications. Claims concerning "phenomena in the world" drive maintenance and enhancement regimens.
Re: The Design of Software is a Thing Apart
#46> Those who speak of “self-documenting code” are missing something big: the purpose of documentation is not just to describe how the system works today, but also how it will work in the future and across many versions. And so it’s equally important what’s not documented. Documentation also (can) tell you why the code is a certain way. The code itself can only answer "what" and "how" questions. The simplest case to sh…
> Some might claim unit tests will solve this Yes. Tests will solve this. Your point is perfect for tests. If another experienced coder cannot comprehend from the tests why something is wrong, then improve the tests. Use any mix of literate programming, semantic names, domain driven design, test doubles, custom matchers, dependency injections, and the like. If you can point to a specific example of your statement, i.…
import cPickle
def transform(data):
with open('my.pkl', 'r') as f:
model = cPickle.load(f)
return model.predict(data)Re: The Design of Software is a Thing Apart
#47Earlier quoted context omitted.
> ASCII_A could be set incorrectly, or have a dumb type, and is more verbose anyway. By using the character directly, the code speaks its purpose. I disagree. ASCII_A speaks it's purpose (we purposefully want an ASCII A stored here). And one can check the constant's definition, and immediately tell if it's correct. E.g. const ASCII_A = 'A' // correct const ASCII_A = 'E' // wrong So: return x >= ASCII_A tell us the in…
return x >= "A"; // ascii A Gets the whole message across in one line, as does using 65 with the comment.
(Ignoring the typo "A" != 'A')
return x >= 'A';
already and only means ascii A. Is there a C compiler anywhere where or likely in future where 'A' in C is NOT ascii A? The comment is redundant if correct, and could be wrong after an edit, so it has no value.
Re: The Design of Software is a Thing Apart
#48Seems to me there might be ways to program that convey more information. For example flow-based programming (FBP) seems like it might help and should help make the flow of the program explicit and obvious. That is, inherent to the code is a high level overview of what it does.
From my own limited experience it can make explaining a program to someone new almost trivial. You just use the various flows defined as almost visual guides to what is happening. I don't want to say FBP is a silver bullet, but I think it points to the idea that it is possible capture much more of the theory and design of the program in the code.
Re: The Design of Software is a Thing Apart
#49Earlier quoted context omitted.
> ASCII_A could be set incorrectly, or have a dumb type, and is more verbose anyway. By using the character directly, the code speaks its purpose. I disagree. ASCII_A speaks it's purpose (we purposefully want an ASCII A stored here). And one can check the constant's definition, and immediately tell if it's correct. E.g. const ASCII_A = 'A' // correct const ASCII_A = 'E' // wrong So: return x >= ASCII_A tell us the in…
How do you know that it's the "E" that is wrong, and not the ASCII_A? Maybe it should be ASCII_E. (If you say it's because it's written twice, well, that's only a valid clue if ASCII_E doesn't happen to be defined too.)
>How do you know that it's the "E" that is wrong, and not the ASCII_A? Maybe it should be ASCII_E.
Ultimately you don't, but ASCII_A requires double the intentional actions to name it and have it also be 'A', whereas 'A' vs 'E' or whatever else is a much easier typo.
It's the whole idea behind NOT having magic values in your code. That is, that:
if (temp > 212)
if (temp > WATER_BOILING_TEMP)
WATER_BOILING_TEMP = 275
if (temp > 275)Re: The Design of Software is a Thing Apart
#50Earlier quoted context omitted.
> ASCII_A could be set incorrectly, or have a dumb type, and is more verbose anyway. By using the character directly, the code speaks its purpose. I disagree. ASCII_A speaks it's purpose (we purposefully want an ASCII A stored here). And one can check the constant's definition, and immediately tell if it's correct. E.g. const ASCII_A = 'A' // correct const ASCII_A = 'E' // wrong So: return x >= ASCII_A tell us the in…
return x >= "A"; // ascii A Gets the whole message across in one line, as does using 65 with the comment.
Without the convenience of autocomplete and re-use in other places in the code, and with a comment that can always get out of sync with what the code does much easier than a named constant.