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 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?

Conclusion


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. =)


[ add comment ] ( 37 views )   |  permalink  |  related link
Downgrading Java on Ubuntu 16.x 
Just a quick note to let everyone know that - after installing LTS 16.04 (so far a very pleasant & stable release - recommended!) that I discovered that the default JDK ("9 internal") does not work.

java -version
openjdk version "9-internal"

--The failures are so bad, that the kernel actually dumps core!



(Forgive the imp, yet note the bug -Halloween is around the corner!)

Sadly, removing the "9 internal" by conventional means results in only a partial removal... very nasty. What will work however, is to remove everything via a hand-grenade:

sudo apt remove --purge "^openjdk.*"

Followed by a dependency purge:
sudo apt-get autoremove

Then re-install a version that actually works:
sudo apt-get install openjdk-8-jre

Ultimately, once we have what we need installed, don't forget to associate that new JRE by right-clicking on a .jar file, so as to:



In addition to those old 'ol reliable versions of Oracle (I like to test under many JVM's), here is the OpenJDK that worked for me on LTS 16.04.1:
openjdk version "1.8.0_91"
OpenJDK Runtime Environment (build 1.8.0_91-8u91-b14-3ubuntu1~16.04.1-b14)
OpenJDK 64-Bit Server VM (build 25.91-b14, mixed mode)


Sharing is caring!


-Rn


[ add comment ] ( 45 views )   |  permalink

| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | Next> Last>>