Perl sucks donkey dick. That bullshit is STONE AGE old. It’s all about JavaScript, n00bs!

I know it is an interface – IT IS PURPLE. I know that it is an instance variable, as the tooltip tells me it is, you MORON. And I have a debugger to boot.

Maybe that is why my productivity is more than yours…

Even without the apostrophe you could strive for adequate uptimes.

BTW: IntelliJ’s explanation of this warning is amusing : “Silly assignment”

Yep. It is, alright.

-Nick

private int interruptTime;

public Foo( int interuptTime ) {
this.interruptTime = interruptTime;
}

As far as the underscores and prefixes are concerned, there is _no_ justification for that. What are you, writing methods that exceed one page? C”mon! And please, take care to minimize the distance between the variable declaration and its first use, and be at peace…

Please try harder Hani.

This is *not* to say their whole writing style guide does, for it sure does not.

As for field/method distinction, there are very few cases when fields should be other than private, as many good reviews will tell you (including Joshua Bloch’s _Effective Java_), which means that most of my fields start with an underscore, a long-standing convention for private field names. Therefore, I very seldom come across a field name that does not, which makes for rare questioning on the nature of identifiers.

As Hani points out, IDEs are quite capable of conveying the difference between static/instance variables, indicating the object’s class etc. And in ways that are far less disruptive than mentally having to parse garbage like ‘mStrObj’ every few seconds. Besides, consistency in style is good regardless, since it avoids having to make small mental mode-shifts as you work across classes (or even within the same class!) where different conventions are used.

As for whitespace, tabs, bracket layout – virtually irrelevant these days thanks to code layout tools, VCS that can normalise the layout etc. AFAIK there are no tools that can normalize your naming conventions, this responsibility falls squarely onto the developer.

So what are you, or anyone else, going to do about it? Throwing bile and name-calling may be fun and all but it does not change anything.

As for Hungarian or other systems of prefixes, I had a bunch of Indian developers who insisted on putting l_local_var, g_global_var, p_method_param and so on. Shrug. To each his own.

Want to go further? What about the tab vs space wars and shall we discuss how many spaces per tab? What about putting open parantheses on the same line or the next line?

We will always have people arguing about it, and stuff like this will never end.

> [...] No less evil is m_thefield, or p_myfield. > Use a civilised IDE if you’re so obsessed about > distinguishing fields from variables, you
> dinosaur.

Why is it bad to distinguish instace field from variables?
Using a good IDE is clearly _not_ a solution as that argument buries naming and coding conventions all together. You clearly are very obsessed about method naming – so what about your IDE doesn’t it help you along?!
And don’t start ranting about coding flow or memorisation issues – your IDE clearly should alleviate those problems also – doesn’t it?!

>without the ludicrous prefix to denote interfaces >and we might consider letting you back into >civilised society.

Discussion about coding and naming styles using non zealot(aka JBoss)-like arguments is very much appreciated. Please enlighten us few turds with your wisdom about naming conventions and particularly as to _why_ they’re good or bad. okay you’ve to actually think about the issues but that doesn’t seem too hard for you.

> It never ceases to amaze me how many people seem > to just not ‘get’ the java naming conventions. I > used to think it’s a matter of common sense […

Why do you think the sun java naming conventions the rosetta stone of java coding. Sun has always had a few good and lots of bad ideas. So why revere and do a singsong about their coding conventions document?