When you need to prevent quick grepping in Java, you can also take advantage of the fact that unicode escapes can occur everywhere in a java file, not only within quotes. So you can declare an int by writing “\u0069\u006e\u0074 \u0069 = 1;” (equivalent to “int i = 1;”)
It's important to use this sparingly. When grepping is obviously broken, the adversary will adapt, most likely by writing a script to rewrite the Unicode, then it's back to business as usual.
On the other hand, if grep has a 95% success rate, the adversary may well never notice, and build his or her mental model of the program on flawed understanding. That's when the real fun begins.
I once worked on a project where every class was named after a martial arts weapon. As cute as that might have seemed, I quickly grew tired of asking questions like, "Should I be using the Shuriken or the Wazikashi here?"
We ended up scrapping that code and doing a ground-up rewrite.
That's how I feel with some dependency-heavy projects I encounter.
Particularly in the Rails and JavaScript package-spheres, every other library has an incomprehensible name that turns out to be an obscure reference to some pop-culture thing (and often some other library as well, to make it even more undecipherable).
I guess it's fun for the developers and makes their résumé look more interesting ("I made a process monitor called Stiglitz, it's named after a Tarantino character!"). But it's tiresome for the person who has to read the code where these characters go about their exciting adventures updating database records, concatenating strings and sending email.
Also; Always name binary variables to avoid hinting to the maintenance programmer which way round they work. Good: result, status, flag. Bad: okay, error, valid.
OP forgot an important tool: store as many variable as possible in one long array. When ever possible use predefined constants like "one," "first," and "superVar" to refer to the index of the desired value in the Array, make sure that all of the above mentioned constants have the same value and are defined in different parts of the code.
Python: put everything in a list, then insert it into itself on multiple positions. Then go nuts using slice syntax. Occasionally use hex or octal numbers.
Short variable names are fine with context. "cs : Customer list" - we know it's a list of customers from the type, no need to repeat. And a loop on it could easily be "for c in cs". Single letters are also useful in local or anonymous functions.
Reuse identifiers? Yes! If I've got a parameter foo that's a string, then I convert it into an int and never use the string again, why not rebind the identifier? It makes it clear the old foo is no longer in use, and prevents such use.
In the interest of fairness, and in regards to the "Underscore, a friend indeed", I'll point to the existence of eg, $_ and @_ as built-in Perl magic variables (you can get away with not using $_, but not @_). I have also been know to use _ for a variable I will not use later (eg, if a function returns two values but I'm only interested in one).
Additionally, in languages with pattern matching, '_' usually works like '*' and matches everything.
It's been a while since I did much perl, but FWIW I seem to recall doing (undef, my $foo) = do_stuff(). Perhaps modern perls have tightened up allowing undef as the target of an assignment.
Number 11 is unbelievably devious. I wonder how many compilers are OK with that?
-----------------------------------------------
Use accented characters on variable names, e. g.
--typedef struct { int i; } ínt;
where the second ínt’s í is actually i-acute. With only a simple text editor, it’s nearly impossible to distinguish the slant of the accent mark.
"If anyone even hints at breaking the tradition honoured since FØRTRAN of using i, j and k for indexing variables, namely replacing them with ii, jj and kk, warn them about what the Spanish Inquisition did to heretics."
Hold on, should we use i instead of ii, or not use it? I fucking hate these double-negative articles.
The article is saying not to mess with the "religious" tradition of i/j/k, which means that the author actually things that ii/jj/kk are better. I don't think it's hard to follow, really, unless maybe if English isn't your first language.
This is a weird one. Using i,j,k for loop values is fine, especially tight inner loops. I can't see that ii,jj,kk adds anything. And I don't see much point in using verbose names like innerLoopIterator or arrayIdx or whatnot for these type of variables either.
Actually later on in rule 20 he implies (with negative logic of course) that i is actually a good inner loop variable name. So that's an inconsistency right there.
If you have to search for loop index variable, your code has worse problems than naming.
I mean - I don't recall writing a loop longer than 2 screens in years. Usually a loop is less than half a screen long.
And anyway, you can search for [^\w]i[^\w] if you really need to.
Maybe it's aquired taste, but in array-heavy code (usually math-related) I much prefer A[i][j][k] * B[j][k][i] than the same with long names for index variables.
jj = <ESC> changed my life; I'm not even joking. I even went so far as to put my zsh in vi mode and added jj there too. (WARNING: doing this will result in a pathological need to type jjk whenever you open a shell to start scrolling through history.)
My favorite way of doing naming in JavaScript is using ಠ_ಠ as a variable (especially if I need to create some sort of quick "hack" to make some sort of urgent issue go away).
Also fun is using reserved JavaScript keyboards inside of JavaScript objects which, while legal, rarely color correctly in code editors.
I search Amazon and Ebay for reserved Javascript keyboards, but haven't found any. I'm now going to search for Javascript objects and hope to find them there!
