|
when testing some javascript thing in browser console, all variables are d of dd
when writing production code, might rename 1 or 2 times.
when writing hobby code, monthly fall system renaming schemes to make all nice
|
|
|
|
|
But you must not use "xxxEnum" ...
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
I've seen MS using 'FunctionameExExExExEx' - is that acceptable?
|
|
|
|
|
If MS says so, it must be! (For now.) It's OK to use _ for private fields (again) too; but only one.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
I have a product which I'm now responsible for that was written by an asshat who followed the option in the subject line. He deliberately wrote the code such that he was the only person who could maintain it. It's written in early 1970's vintage C, even though the product was started in 1990. Everything is global. There are types and variable names that are single, lower-case characters. Most identifiers are 6 characters or less. Source file names do not denote their contents. Header files do not declare the functions in the corresponding source files, if they even exist. Function prototyping isn't used - at all. The wacky guy even redefines #define 'd constants in windows.h because "Microsoft did it wrong".
This product was not under active development, so management assigned the guy to another product. For six months he refused to do any work. At the end of that time he was 'spoken to', and responded by retiring with no prior notice.
I've made exactly one change to this product, to replace support for some obsolescent hardware. It took over 100 hours of preparatory analysis to locate and verify all of the potential side effects, and a little over 4 hours to code, debug, and test the replacement.
I've been a professional programmer for a little over 42 years. In all that time I've worked with people I didn't like, but I've only hated one: this guy.
Software Zen: delete this;
|
|
|
|
|
Wouldn't it be faster to just re-write the thing from scratch?
|
|
|
|
|
I could probably rewrite it in 12-18 months, if I could spend full time on it. Unfortunately the demand for this product line is waning, and wouldn't warrant the effort.
Software Zen: delete this;
|
|
|
|
|
You could consider it fortunate that the demand for that product line is waning as then it won't matter.
|
|
|
|
|
That story reminds me of when I went to work for a manufacturing company in Dallas many years back. One of my first tasks was to update/complete an existing ASC X12 application that my predecessor has created, that was not quite functional yet. Basically handling purchase orders (850 Documents) and putting that data into a Btrieve database for Micro-MRP Max Manufacturing and Requirements Planning software that the company ran on.
There were no defined structures anywhere, everything was a void pointer with memcpy operations to the void pointer address plus an offset. I told my boss, I can either update his code, which would take a couple of months at a minimum, or write a fully functional replacement from scratch in a couple of weeks that was much easier to maintain. I ended up writing a replacement from scratch. That initial work became the inspiration for for a full blown ASC X12 class library I wrote in my spare time and licensed to the company free of charge. Developed a parser that interpreted the ASC X12 documentation and generated classes for each complex data type and document type.
Eventually, I ended up licensing out that class library to a few other companies as a side hustle.
|
|
|
|
|
Have seen a Stanford University video in which he shows a coding horror:
#define SEVENTY_TWO 73
|
|
|
|
|
... I really hate it... No knowledge about the business, but only correct namings
|
|
|
|
|
Consider yourself lucky.
Sometimes, computer people break into professional fields they do not know, forcing onto it their own misunderstanding of the terminology, twisting it around badly. But they are such holy, untouchable gurus that noone dares lift their voice against, and tell that 'But that is not what is meant by that term!' Rather, the misunderstood use is taken up as the new, modified meaning.
E.g. pick up a textbook on typography, 30-40 years old (or more): It uses the wrong terminology! Oh well, at that time it was The established terminology, but then came this holy guru saying things differently, and we had to adjust to him. He is holy and untouchable, and he has made his own font and typesetting system. We must follow what he says, or we are doomed.
|
|
|
|
|
...that's all that needed to be said about being "careful" with naming (and writing in general)
|
|
|
|
|
I used to work with a developer who named all of his variables in 4 letters or less, all the variables. No one could read his code.
I agree with the overthink part, but there are a lot of developers who don't think...at all, about anything.
|
|
|
|
|
As a native german speaker, we often have the effect, that (more unexperienced) devs have a mixture of german and english variable names in their code...
that's so horrible, because the brain needs to switch between languages all the time.
i tell my students day-in and day-out "devs _think in english_. your variables are _english_. your class names are _english_. And so are your comments"
you wouldn't believe how hard this seems to be to many of them.
they take whichever word they like better for a specific thing, and the most bizarre are denglish variable names like "mausOver" instead of "mouseOver" ... that looks so... _whaaaaaat?_
|
|
|
|
|
Mike (Prof. Chuck) wrote: devs have a mixture of german and english variable names in their code... that's so horrible, because the brain needs to switch between languages all the time. Agree 100%!
When I code, my brain switches to English. Names, comments etc. 'must' be in English. (That also makes it more natural to keep all prompts etc. in separate language defined files: If I make the first version of the program with a non-English user interface, I stall if I inadvertently add an output string in an non-English language.)
I have rejected, an open-source library because all the variable and function names, as well as comments, were in French.
Old memory from my student days as a Teaching Assistant (but this happened to Jon, another one of the TAs):
The professor insisted on mixed language programming, i.e. Norwegian variable/function names, in spite of the English Fortran language context. Fortran had no explicit variable declarations, so if you misspelled a variable name, you implicitly declared a new variable. When Jon realized that was the very problem in the program of the young female freshman, he loudly exclaimed "Look, here you have written 'K0E' rather than 'KOE'" ('kø' means 'queue', but as Fortran doesn't allow 'ø', it it was replaced by 'oe'). The problem is that 'k-zero-e' in Norwegian is 'k-null-e', pronounced just like 'f**k' in Norwegian ...
When you are a 20 yo male TA, declaring all over the terminal room for everybody to hear, to an 18 yo beautiful female freshman: "You have written 'f**k' in your code!", and discovering it half a second late, then your day is ruined
Today, Jon laughs of the story, but when it happened, his own embarrassment was much stronger than the girl's.
|
|
|
|
|
trønderen wrote: The problem is that 'k-zero-e' in Norwegian is 'k-null-e', pronounced just like 'f**k' in Norwegian ...
When you need another variable for counting, but count has already been used, some people just leave out the o ...
Oh sanctissimi Wilhelmus, Theodorus, et Fredericus!
|
|
|
|
|
Mike (Prof. Chuck) wrote: i tell my students day-in and day-out "devs _think in english_. your variables are _english_. your class names are _english_. And so are your comments" You haven't lived until you've tried to understand code with identifiers and comments written in a mix of English and Japanese .
Software Zen: delete this;
|
|
|
|
|
I spent the better part of two days trying to make dbContext give me up to the picosecond data. Oh the "code around" it took. It's done now.
As for naming, I try to be nice to my future self and anyone else that may unearth this abomination.
|
|
|
|
|
Especially since I joined not less than a dozen teams, some of which with prescriptive coding rules (due to regulations).
So I often end up refactoring my code before pushing in order to adapt to the current rules or layout.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
Code should be as self documenting as possible. Having simple, descriptive names for your methods, classes, and more importantly your variables is critical, and is key with self documenting code.
var serviceTypes = new List<ServiceType>();
instead of:
var st = new List<ServiceType>();
|
|
|
|
|
I've been working on retiring some VBA code out of critical business processes. One of the previous incumbents was a great lover of single character variable names and two character function names.
I have actually seen something along the lines of
Dim s As Range
s = gr() Every. Other. Module. has s As String
|
|
|
|
|
Some programmers are unable to control themselves, thinking that "Longer is better - unconditionally and always!"
So they consider the variable name 'Price_paid_for_the_product' to be far better than 'Price'. To turn on that visual signal labeled 'LED1' on the circuit board, they insist to program 'Light_emitting_diode_one = On' rather than 'LED1 = On'.
I was in a project at a time when the company programming style standards were revised. Our project leader granted an exception from one of the coding rules: No statement longer than 80 characters. The problem was that the project naming rules frequently lead to names exceeding 80 characters. I never thought that those names improved readability.
In other projects, I have implemented protocol standards where the standard defines a set of states and a set of events identified by abbreviations / acronyms of 3-5 characters, predicates identified as p01 to p67. When you make a direct implementation of this standard, it would be silly to attempt to de-abbreviate or de-acronymize state and event names and make up some strange, unknown 'descriptive' name for the predicates, in order to 'improve the readability' of the code. It strongly distorts the reading of the code.
I have similar problems with papers and articles that seem to think that the reader (presumably a professional, or at least semi so) is completely unfamiliar with basic, well established terms. So throughout the text, they write e.g. 'CPU (Central Processing Unit)' and 'DMA (Direct Memory Access)' and 'RAM (Random Access Memory)' - not only when the term is introduced, but throughout! I get the feeling that these people would write 'VB6 (Visual Beginners All-purpose Symbolic Image Code Version 6)' on every reference to VB6 as well ...
So please: Use common sense. When 'readability' has reached the level of 'no ambiguity whatsoever', there is no need to use a phrase rather than a name to refer to a variable, value or object.
|
|
|
|
|
Well there is an acceptable balance.
I come from the shorthand generation (and I'm kinda getting the hang of camelCase). I vaguely remember a convention about anything starting with uppercase is a function and lowercase is a variable, and it extends to objects as well (objects are just another form of data structure with pointers to functions)
That said, reading the context of a program, one can easily understand
gmTabWidgetL to be "GeoMechanical tabulation widget, on the Left" (it's gui code). The word Geomechanical is in both a comment and in a text label before the code.
So that's pretty well documented I'd say.
But rather unfortunately Python doesn't use types to declare variables so figuring out that thing was an object requires some detective work in finding the assignment of the name and the object's constructor.
In the end I think people who can't be bothered with deducing a variable's full name or function, should consider alternative careers. Computer programming is about instructing the calculator what to do, not chatting with the layman.
|
|
|
|
|
Outdated options - in modern languages you have thousands of options for single letter names, not just 26. Hieroglyphs always makes the code look nicer - and you can of course throw in the odd Klingon character just to spice it up a bit.
|
|
|
|
|