Site Sponsors:
Beware The Code Nazi! 
If you are the type of software developer who believes in the purity of how one must name member functions, variables, as well as preferred spaces about thereof, you are not alone.

From Python to Java, I have encountered many who believe that "their way is the only way."

Ever arguing over the proper way everyone ELSE must write THEIR OWN CODE, the truth is that it is not uncommon to see - for example - Python software developers using Java coding styles.

Should anyone care?

Personal Style

Believe it or leave it, lots of people feel that software development is a creative process. Much like the creation of masterpieces in all works of art therefore, surely software developers should be free to use whatever naming & formatting styles each feels most comfortable with?

On the professional level, many software development teams agree upon a single, unifying way of formatting & naming various key elements in their code. Documented as a "CODING STANDARD," most tenured software developers know that such coding conventions allow diverse software developers to readily understand ALL code written by THEIR OWN teams.

Bucking The Standards

Moreover, from time to time there can also be a need to improve existing industry conventions!

In my case, while the Java "Code Nazis" will insist that all member functions be named in "Camel Case" with the first case lowered (see below), when it comes to naming STATIC member functions, I prefer to use the same case as the recommended class name, or pure camel case.

Why? Because

class MyClass {
public void memberFunction() {}
public static void MemberFunction() {}

allows us to quickly appreciate, locate - as well as ''orally overload'' - class-associated members who - like the class itself - do not require an instance for us to use them.

... It is a logically homogeneous kind-of thing?

More Pattern Recognitions

Moreover, one might find it difficult to see those minuscule icons often used for denoting "protected" and "private" scopes (usually placed out of eyesight) in their IDE...

public class HeilNada {

public void myFoo() {}
protected void _myBar() {}
private void __myNet() {}

public static void MyFoo() {}
public static void MyBar() {}
public static void MyNet() {}

public static void main(String ... args) {
HeilNada zNada = new HeilNada();


If one never cares enough to move one's eyes off of ones code long enough to manage those cryptic little beasties, just as surely one might ALSO like to use the far-more sorted & dot-discernible "_" and "__" prefixes in Java - as used in C/C++ and Python - no?

Surely the above is allot better than the Nazi's preferred:

public class HeilNada {

public void myFoo() {}
protected void myBar() {}
private void myNet() {}

public static void main(String ... args) {
HeilNada zNada = new HeilNada();


only so as to force everyone else to choose between:

Indeed, the more member-code there is to choose between, the better the advantage of using underscores - or other common member prefixes - so as to implicitly order selections for your team, will be:

Meaningful Variable Names

Surely any professional who has switched between several companies has also discovered how to tolerate more than one coding standard?

In a like manner, I often like to use German Notation. Competing with variable-naming standards such as Hungarian Notation, (which I also like to use!) the point is that each and all of these standards add a much finer grain of code understandability, as well as self-documentation. -Many have discovered that an objectified update for Hungarian Notation (sort-by nouns, Latinize verbs, drop vowels & dual consonants - another story!) adds the clarity required to avoid allot of errors... Certainly when working with Python and / or other typeless languages!

Much like the standards other notational conventions often augment however, with rare exception (test-time postmortems, real-time code spelunking, etc), each add absolutely nothing to the overall effectiveness of the software that we create.

Personally, I worry that forcing our planet into doing everything the exact same way simply favors unimaginative, intolerant, and / or inexperienced minds. Rather than allowing ourselves to become overly intolerant therefore, surely we all need to learn how to think-past any and all of our own creativity comfort zones? No pain, no gain?


In as much as much of what has been noted above could apply to either local and / or global style-proponents, here be the crux of the globalists dilemma: Given the absolute personal merits offered by merely considering alternative ways of doing things... And given that even the above style suggestions obviously add some very real understandability & time saving values (time is money!)... should you and I not be free to prefer a BETTER way... or should we be allowed to be persecuted by those (Heil PEP-08!) Code Nazis?

Sadly - and for the moment - the NWO seems to be favoring far too many of those oh-so easily-offended & obviously ignorant fascists. Nevertheless, allow me to note - despite the ridicule - that most REAL software development professionals will always favor that "Gold Standard."

Also known as the "Golden Rule," the idea is that 'dems whose be paying us 'da gold, gets to be making-us 'da rules.

Surely if one ever wants to become a professional software consultant, then one's own mileage - certainly when navigating over such a bumpy cross-language stylistic terrain - won't much vary. =)

[ view entry ] ( 448 views )   |  permalink  |  related link

<<First <Back | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | Next> Last>>