Poor naming practices
Closed this issue · 2 comments
Description
I know this is not a feature request but I do not know where else to raise this issue.
While perusing this codebase I was extremely disappointed to see names such as DeclSyntax, ExprSyntax, StmtSyntax etc. the use of such abbreviations in names is NOT acceptable. The Swift Naming Guidelines explicitly reject such names and clearly state that CLARITY NOT BREVITY is the name of the game, they also further state that CLARITY AT THE POINT OF USE is more important than at the point of declaration. You can NOT justify the use of such arbitrary and ridiculous abbreviations with any rational argument.
No doubt the excuses for the use of them will range from
a) the names are too long otherwise, which is rubbish for two reasons i) omitting those few vowels is NOT going to produce any significant improvement in the time taken to type such a name if one is a halfway decent typist, and ii) it’s more likely that given the arbitrary nature of such an abbreviation, remembering the exact abbreviation will take longer than just typing out the name in full,
b) Apple does it, which is also nonsense because i) Apple is not god therefore one should not just blindly follow it ii) Apple should be setting the example not violating the guidelines iii) Apple can and does make mistakes therefore it’s actions need to be critically analyzed not swallowed whole, iv) Apple should be even more vehemently condemned for such violations because it knows people will ape it v) something is good or bad by virtue of merit not its origins, and vi) just because Apple does something does not axiomatically mean it has merit,
c) Chris Lattner, Doug Gregor, some other genius programmer does it, see the points regarding Apple doing it,
d) why is it done in some places but not in others, e.g. ExpressionPatternSyntax is spelled out in full, so why isn’t ExprSyntax or StmtSyntax etc ? In other words even the “rule” used to decide when to violate the Naming Guidelines is not consistently applied. This also negates the defense that the length of the names dictate the use of abbreviations because some names with abbreviations are vastly longer than names without abbreviations. The logic behind abbreviating names in such a fashion is flawed and can neither be rationalised nor justified
e) there is not even any internal logic in the abbreviations used such as, for example, only removing vowels as they may be considered superfluous. If you are going to pollute the namespace with such abbreviated horrors then at least consistently use such horrors,
f) just because coders working on these packages may be, or may consider themselves to be, advanced/senior/experienced/genius coders that does NOT grant them the right to violate standards willy nilly. Standards apply just as much to god level programmers as they do to interns. In fact seasoned coders should more rigorously apply the guidelines because i) they, if anyone, by now, should understand the benefits of consistently applying standards and ii) they know other people are going to copy their code and use it as an exemplar, therefore they should be even more rigorous than most in adhering to guidelines. To those whom more is given, more is asked.
g) the argument that the abbreviated names are equally clear or do no harm is false because i) your rules and reasoning around using abbreviations are not defined nor are they applied consistently leading to ambiguity ii) the mentality of coders who think such names are acceptable is questionable because it’s based in laziness not in logic and if they are taking shortcuts when naming things what other shortcuts are they taking as well ?
This arbitrary abbreviation of names must be stamped out. It is NOT good programming practice. For example calling an induction variable “i” can be justified if the code in question is perhaps, for example, the expansion of a summation (i.e. sigma notation ) expression that happens to use “i”, but what happens when the summation uses an interest rate, where the “term of art” delineation of an interest rate is “i”, does one just rename the induction variable to “j” which is almost as meaningless as “i” or does one stop being lazy, grow up and call the induction variable “index” which is not ambiguous the way “i” or “j” are. The mentality behind abbreviating almost every name is truly infantile, what actual benefit does using a variable called “lbl” give you over “label”, NONE, it’s only because programmers are extremely lazy, because they refuse to think clearly ( if at all ) about naming, because they think it somehow makes them cool and skilled rather than moronic and selfish, because they think they’ll always remember their intent and we all know in 12 months they won’t and because they fail to internalize that one doesn’t name things or comment things or structure things correctly for the benefit of others, one does it because it is the rational thing to do and because it will benefit one the most.
Please, please, please stop with this bad practice. To even attempt to justify it is in itself infantile. Naming is difficult and hard work but it can make code simple to maintain or impossible to assimilate. We don’t need clever code, or slick code or cool code or compact code, we need well structured, well named, well designed, well thought out code that is easy to understand and easy to change. Bad naming is not a testament to ingenuity and genius, rather it is a testament to laziness, intransigence and a lack of insight.
Synced to Apple’s issue tracker as rdar://127261846
Okay. This is repeatedly crossing the line of the code of conduct. You can file a new issue without all the personal attacks.