44 ms·
Well, maxPA, or MaximumPhysicalAddress both satisfy different goals more effectively. maxphysaddr is almost an example in my mind of how not to name things, in
by dwringer 10y ago
Well, maxPA, or MaximumPhysicalAddress both satisfy different goals more effectively. maxphysaddr is almost an example in my mind of how not to name things, in that it relies on abbreviation conventions that different programmers may not use consistently. As you said, within a codebase it's probably no big deal. I just think it's a bad example of a good name. I don't agree with your logic about criticism requiring an alternative.
- microcolonel 10y agoIf the purpose of criticism is to improve the state of the art, then what is the point of unexplained criticism without alternatives? Other purposes of criticism don't seem appropriate here. The abbreviations max and addr are found in colloquial English. Even phys is used in abbreviations like phys ed (physical education). Phys is the start of about 20 distinct words. Among them, physical has been the frontrunner in frequency since the late 1820s. [0] The only part of the abbreviation which would be confusing to a non-programmer, is the specific use of address in this context; but if you are working in a language which directly manipulates memory addresses, you should be able to expect that of the reader. maxPA is completely ambiguous (maximum pool allocations? maximum potential acceleration?), and it would need to be recalled, rather than recognized. On the other hand, MaximumPhysicalAddress is ridiculously huge, and would be impractical to use inline in an expression; at exactly twice the length of maxphysaddr, it conveys the exact same amount of information while being less practical to type, format, and read. Indeed, people might end up copying the variable to a local name just to fit it in their expressions. In C, it also conflicts with the common convention of making typedef'd struct names uppercase. [0]: https://books.google.com/ngrams/graph?content=physics%2Cphysical%2Cphysicality%2Cphysically%2Cphysician%2Cphysicist%2Cphysicked%2Cphysicking%2Cphysio%2Cphysiognomy%2Cphysiography%2Cphysiologic%2Cphysiological%2Cphysiologically%2Cphysiologist%2Cphysiology%2Cphysiotherapist%2Cphysiotherapy%2Cphysique&year_start=1800&year_end=2000&corpus=15&smoothing=3&share=&direct_url=t1%3B%2Cphysics%3B%2Cc0%3B.t1%3B%2Cphysical%3B%2Cc0%3B.t1%3B%2Cphysicality%3B%2Cc0%3B.t1%3B%2Cphysically%3B%2Cc0%3B.t1%3B%2Cphysician%3B%2Cc0%3B.t1%3B%2Cphysicist%3B%2Cc0%3B.t1%3B%2Cphysicked%3B%2Cc0%3B.t1%3B%2Cphysicking%3B%2Cc0%3B.t1%3B%2Cphysio%3B%2Cc0%3B.t1%3B%2Cphysiognomy%3B%2Cc0%3B.t1%3B%2Cphysiography%3B%2Cc0%3B.t1%3B%2Cphysiologic%3B%2Cc0 https://books.google.com/ngrams/graph?content=physics%2Cphys...
- jmts 10y agoTo this I would like to draw attention to the mention of context in this example, which I think is important and often looked over when naming variables. The context given for maxphysaddr is that of a global variable. Pike also mentions loop indices, which have very local scope. A loop variable can be very short because you know everything about it simply by reading the few lines around it. A global must encode much more information in its name, because its context is spread globally. If the name is not good, the developer has to spend extra time looking for appropriate context, and aside from the added frustration, time is money. In some ways one could suggest that variable name length should be proportional to its scope. This isn't quite true, however, because we should then find that MaximumPhysicalAddress should provide greater value than maxphysaddr. Instead, we find that MaximumPhysicalAddress is a worse name due to its length. They are however both unambiguous and provide the same semantic information. This suggests that perhaps a rule of thumb should be that the name unambiguously encode the necessary semantic information proportional to its context, and no more. Naming is however hard, in general. It seems picking good examples is equally difficult.
- dwringer 10y agoThat's exactly my point. I did not offer MaximumPhysicalAddress originally as an alternative, because as you said it is not really any less ambiguous in this case. However, a new programmer approaching the codebase still has to remember WHICH words are abbreviated and which variables rely on which abbreviations. Since MaxPhysAddr is already 11 characters long, and I can type MaximumPhysicalAddress in almost exactly the same amount of time (the overhead is essentially negligible) I see no benefit to using the abbreviated form. One must remember that maxphysaddr actually carries MORE information than MaximumPhysicalAddress, specifying that the words are all abbreviated. One can argue that the abbreviations used are conventional, but if the convention is not already known then the information required is even greater. That information is not relevant to the variable's function, and thus adds an unnecessary burden to the programmer. IMHO. But, again, it is not a good example, and I do not have a suggestion for an alternative.
- deleted 10y ago[deleted]
- oneeyedpigeon 10y ago> maxphysaddr is almost an example in my mind of how not to name things, in that it relies on abbreviation conventions that different programmers may not use consistently Pike deals with this very issue in the article: > np is just as mnemonic as nodepointer if you consistently use a naming convention from which np means ``node pointer'' is easily derived
- dwringer 10y agoI dealt with that very issue in my comment - "it relies on abbreviation conventions that different programmers may not use consistently". Different programmers at different times follow different conventions, no matter how overwhelmingly obvious they are at the time. Changing adds to the already huge burden of context switching.
- oneeyedpigeon 10y agoHow can you possibly account for that though? Different programmers speak different natural languages, yet most public codebases still use English. Certain terms will fall in and out of fashion over the course of time. Consistency within the project is the most important thing we can control.