We Keep Coding

Why are Java naming conventions not enforced? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Java has strong naming conventions for class, method, field and variable names.
For instance:
Class names should start with an upper case character
Methods, fields, and variable names should start with a lower case character
The JDK has only few exceptions to these two rules.
But a convention is not a syntax rule, and therefore classes like the following compile without errors (C# programmers would be happy anyway):
public class string {
private char[] C;
public int Length() { return C.length; }
}
But the gap between a convention and a syntax rule inevitable leads to violations of the convention by beginners which then leads to lengthy explanations about naming conventions.
If the most fundamental naming conventions (like the one cited above) would be part of the syntax then the Java compiler would enforce them and automatically educate those beginners.
So here is the question:
From the Java language designers point of view: Is there any good reason to leave a gap between syntax and naming conventions which should never be violated? Are there any meaningful use cases for namings (of classes, methods, fields, variables) which violate the convention but make sense beyond the convention?

The conventions were written long after the language was defined so they could be retrofitted without breaking compatibility. The problem with conventions are they involve taste. e.g. spaces or tabs, using $ as a variable name, starting field names with m_ or _ etc. even wither to add get and set to getters and setters (which I prefer not to)
Java actually allows you to do things which would make C programmer feel queasy. Why they allowed this I don't know, but I assume they didn't want to limit adoption by imposing more rules than really needed.
Note this is a piece of Java code is valid due to the use of a character which probably shouldn't be allowed but is.
for (char c‮h = 0; c‮h < Character.MAX_VALUE; c‮h++)
if (Character.isJavaIdentifierPart(c‮h) && !Character.isJavaIdentifierStart(c‮h))
System.out.printf("%04x <%s>%n", (int) c‮h, "" + c‮h);
Most IDEs will help beginners write code which follows conventions. The only problem with this is most developers don't know how to make full use of their IDEs. ;)

Well, personally I think the reason for not enforcing conventions is simply because of the fact because it's technically not really necessary. Counterexample: E.g. in Java you have to name the class file exactly like the class because the Java Class Loader could not load it otherwise. Building these checks into the compiler would bloat the source code and as the name tells it, a compiler converts source code into machine code / byte code / whatever by parsing the source files and checking the syntax. Checking whether a class starts with an uppercase or lowercase letter is simply not the compiler's job.
And of course a programming language gives you a certain degree of freedom by not enforcing such things as conventions to style your code how you like it if it matches the syntax rules of the language.

Well, if I use some Chinese characters in identifiers, there are no upper/lower cases for them:) So the convention cannot be always enforced.
Of course, it's pretty safe to bet that 99.9% Java code are in English. And you may also argue that the enforcement can be limited on some charsets only.
I agree that this naming convention has become critical, and it should be strictly followed. A java source code that does not follow the convention is practically incomprehensible.

From the Java language designers point of view: Is there any good reason to leave a gap between syntax and naming conventions which should never be violated?
Yes. "Never" is a strong word.
The language has requirements and recommendations. The language specification for identifiers is a requirement. But those strong naming conventions are recommendations.
Having some definition of identifiers is necessary for the compiler to recognize them as tokens. Leaving that definition looser than the norm gives us a little freedom for cases outside the norm.
Are there any meaningful use cases for namings (of classes, methods, fields, variables) which violate the convention but make sense beyond the convention?
Yes. Java programs can interact with other languages, which have different conventions.
Code conversion
Sometimes when hand-converting code from another language, leaving the original case is easier and more understandable.
Code generation
Sometimes we generate code from a specification that was not written for Java. For example, we might generate code from a WSDL file, or generate wrappers using SWIG.
Code wrappers
Some Java methods can wrap external functions. For example, JNA allows defining interfaces with a native function's name and signature.
JVM languages
Multiple languages can run atop the Java virtual machine. These other languages have their own conventions. It's possible to mix languages in a single program. Stepping outside the convention can be necessary to interact.

I guess this is why it's only conventions and not rules... I don't see why should it be enforced, there are many other conventions which are not enforced (e.g. putting constructors before alother methods, putting public methods before private methods and many more), it would be too strict (in my mind at least) to enforce it all.
I can think of one case you don't want this convention to be enforced - it's also common to write consts variable in uppercase- again, just a convention.
In any case, I think that in most IDE's you can configure it to give a warning when such conventions are violated. this can help you I guess

Questions about Java code styles [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
So I have seen a lot of different coding styles, but I'm only going to talk about two big ones. I use a style where I just name everything like their class name when used in a general sense, like this:
String str = "This is some text";
But over at Java Practices, I see a style where they will put an 'I' in front of Interfaces class names, or they put 'f' or 'a' in front of object names. Take this snippet from "Don't subclass JDialog or JFrame"':
/**
Constructor.
<P>Called when adding a new {#link Movie}.
*/
MovieView(JFrame aParent) {
fEdit = Edit.ADD;
buildGui(aParent, "Add Movie");
fStandardDialog.display();
}
Why do programmers code in this style? Do a lot of people use it? And also, do professional programmers use this style?
Thanks in advance :)

This my personal opinion.
I prefer not to use prefixes on interface (or anything else for that matter). I just prefer to call it what it is. Interfaces are meant to represent an object (or part of it) without making any implication towards it's actual implementation.
Say you have a Car interface. And AudiA4 could be an implementation of that car. If you just bought a new Audi A4, you say, "I bought a new AudiA4" to those you think care about the kind of car you bought. To others, you can say "I bought a new Car". Certainly, you never say, I bought a new IAudiA4 or a new ICar.
The JFrame naming came about because it's a Swing Frame and Swing came after AWT (the original Java windowing toolkit, which already had a Frame class). Since both AWT and Swing where available at the same time, they used the 'J' prefix to demarcate the toolkits (note that JFrame extends Frame, btw). They could have called it SwingFrame but the 'J' prefix was apparently a good choice to represent the Swing package. So basically this prefix is just a naming choice, not a convention similar to the 'I' for interfance (or Impl suffix for implementations you see sometimes as well)
My point is you always have to name your classes and interface according to exactly what they represent. No more, no less. No point having a CarImpl class. Who cares that it's an implementation. Which implementation is it? Why does it need its own class? What more do I get when I use a CarImpl? What happens when I make a second implementation, I call it CarImpl2? All this is very constraining and doesn't bring much value.
Call it what it is. That's the only rule I'd set forth.
All this being said, the Eclipse project, amongst many others, does indeed use the I-for interface notation (WIKI). But it's their choice. I've seen professionals use it as well. I don't like it, but generally speaking, I respect the team's naming convention.

There is a book about such things - Code Complete by Steve McConnell

I might be wrong but the only universal convention I've seen when naming Java variables is using Camel-Case notation, that's regarding the format of the name.
As for the name itself, I've always found useful to name the variables according to what they actually are. In your String example, although you mention this would be in a general purpose variable, I would still give it a more meaningful name, like:
String message = "This is some text";
Or:
String msg = "This is some text";
Some of the Java libraries I've seen source code from tend to be quite verbose when naming variables, others just use single letter names when the variable is used in a reduced context:
public Rectangle setLocation(Point p) {
return setLocation(p.x(), p.y());
}
I think the main goal when naming variables (or anything else for that matter) is always to communicate in the best way possible the intent of what you were trying to do.

Code styles help make it easier for developers to read and understand each others code. Java conventions prescribe the use of short and descriptive identifiers, but unfortunately short and descriptive cannot always be achieved together so you may have to compromise shortness for clarity hence: atmosPres - still clear but short, atmosphericPressure - this can't be mistaken, atm - because everyone just knows ATM, right?, ap - WTF?
I first encountered the practice of prefixing variable names with a three letter type identifier while developing programs in C# - it helps the reader know what data type is contained in a variable without having to look for its declaration (due to short memory or maybe laziness?). Arrays are also prefixed with I e.g IList to distinguish them from other data types (and for what purpose, I just dunno).
For me, the worst code conventions are in C++ (if indeed there are any at all) - there's a mix of case types for data types and variables, conflicting method and function naming styles and endless cryptic abbreviation which all make it hard for non-regular C++ coders to read and understand C++ code.

What you're describing is sometimes referred to as "Hungarian notation", though it's not "Hungarian" in the truest sense of the term.
Basically, the idea is to differentiate between different classes of variables -- instance variables, local variables, parameters, et al. This serves two basic purposes:
It helps avoid name collisions, where, say, there might naturally (using "descriptive" variable naming) be an instance variable ralphsLeftFoot and a local variable ralphsLeftFoot. Using a prefix allows the two to co-exist, and, especially in languages where the local might (without warning message) "hide" the instance variable, prevents unintended changes in semantics from such collisions.
It makes the scope of variables obvious, so that, during maintenance, one does not accidentally assume that a local variable has instance scope or vice-versa.
Is this approach worthwhile? Many developers use a subset of the scheme, apparently to good effect. For instance, many Objective-C developers will name the instance variable behind a "property" with a leading "_" character, to clearly differentiate between the two and to avoid accidentally using the instance variable when the property was intended.
Likewise, many developers in a number of languages will prefix instance variables with a letter (often "m") to differentiate them from "normal" local/parameter variables.
What's probably most important is to pick a style that you (and your team) likes and stick with it. If the team likes the prefixes then use the prefixes. If the team prefers something else, stick with that. Of course, changing preferences, when a better choice is "revealed" to you, is OK, but don't switch back and forth willy-nilly.

So I have seen a lot of different coding styles, but I'm only going to
talk about two big ones. I use a style where I just name everything
like their class name when used in a general sense, like this:
String str = "This is some text";
That is awful. Imagine if someone were reading your code, trying to understand what it was doing, and they came across a variable named str. It doesn't convey any meaning to the person who has to read this code as to your intentions.
Conventions are used by and for people to improve readability, and thus the overall quality of software. Without a convention, any project that has more than one developer will suffer from varying styles that will only hurt the readability of the code. If you want to know what professionals do, look around on the internet for various conventions.

Why do Java programmers like to name a variable "clazz"? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I've seen lots of code with declarations like Class clazz. Where does this originate from? Is this some kind of convention? I think ‘clazz’ is not even an English word, has no meaning at all, how can so many programmers name a wrong name coincidentally?

clazz has been used in Java in place of the reserved word "class" since JDK 1.0. "class" is what you want, but abbreviating or inserting junk ("a", "the", "_", etc) reduces clarity. clazz just says class. "International" English speakers (those reading both British and American English) are used to transposing 's' and 'z'.
Since Java has had disclosed source and a suitable culture right from the start, worthwhile Java code and tutorials pick up the same conventions. That's one of the great things about the Java ecosystem, which I think has been an important part of its success.

Because they cannot use the word they want to use which is class. It is reserved.

It's simply because 'class' is a reserved keyword, hence Class class isn't allowed. Therefore you'll see Class clazz or Class cls.

It comes down to the actual compiler and its ability to distinguish what a token means within its context. However, in this particular case, it is the compiler's inability to distinguish what the token class means in a different context. It is a hard and fast rule that class, regardless of its context, is used to denote the declaration of a class, and as such it is a reserved word. That is as simple and as low-level as it gets.
If you feel compelled, you could write your own Java compiler to include a contextual rule that will allow you to use class as a variable name. Though I think it would be far better use of your time to just use clazz or klass -- it would probably be good for your health as well.

Declaration Class clazz is popular in Java world, but it may be awkward for newcomers and spellcheckers. I've heard some people saying that it should be avoided according to principle of least astonishment.
As it is possible to say that a Class object represents a type, I personally prefer to declare such variables as Class type.

where does this originate from ?
I saw it first at Josh Bloch's puzzlers. But I'm pretty sure it was used much earlier by other developers. Josh Bloch just made it more famous.

Java does not have a feature that allows you to use a keyword as an identifier, unlike C# with its # prefix (e.g. #class is a valid identifier.)

It is just a English word replaced(Equavalent) by Keyword Class Keyword, to make people understand that it is a Class. and it is almost to increase the readability of the Code
Nothing big Logic involved in this

We use clazz because class is a type header. For example, you use class here:
public class HelloWorld {
and here:
Object.class.getName();
So unfortunately, we have to use alternate names such as clazz.

what are the major differences and similarity in java and ruby? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I am java professional now I like to go for ruby.Are there any similarity in both the languages? and what are the major differences? As both are object oriented.

What about these:
Similarities
As with Java, in Ruby,...
Memory is managed for you via a garbage collector.
Objects are strongly typed.
There are public, private, and protected methods.
There are embedded doc tools (Ruby’s is called RDoc). The docs generated by rdoc look very similar to those generated by javadoc.
Differences
Unlike Java, in Ruby,...
You don’t need to compile your code. You just run it directly.
All member variables are private. From the outside, you access everything via methods.
Everything is an object, including numbers like 2 and 3.14159.
There’s no static type checking.
Variable names are just labels. They don’t have a type associated with them.
There are no type declarations. You just assign to new variable names as-needed and they just “spring up” (i.e. a = [1,2,3] rather than int[] a = {1,2,3};).
There’s no casting. Just call the methods.
The constructor is always named “initialize” instead of the name of the class.
You have “mixin’s” instead of interfaces.
== and equals() are handled differently in Ruby. Use == when you want to test equivalence in Ruby (equals() is Java). Use equal?() when you want to know if two objects are the same (== in Java).
Taken from: To Ruby From Java

Besides being object oriented there are very few similarities between the two languages. Java is a statically typed compiled language while ruby is a dynamically typed interpreted language. The syntax is also very different. Java uses the c convention of terminating lines with a semi-colon while ruby uses the return character.
While Java does have some built in support for iterators ruby's uses of iterators is pervasive throughout the language.
This obviously only touches upon a comparison of the two. This is a decent write-up on the comparisons

You're asking a very broad question. I like to compare scripting languages similarly to how I'd compare spoken languages, so in this case; what are the major differences and similarities between Spanish and Italian?
If you ask that question, you're going to either get very varied or very long answers. Explaining differences between languages are difficult at best, as it's hard to pinpoint key factors.
This is proved by the responses here so far, as well as the links other people have linked to. They're either varied or very long.
Going back to the Spanish vs. Italian analogy, I could say that the languages are similar but still very different. If you (only) know one of them, you might be able to understand what's going on in the other, though you would probably not be able to use it very well. Knowing one definitely makes it easier for you to learn the other. One is used by a larger number of people, so you might benefit more from learning it.
All of the previous paragraph can be applied to Java vs. Ruby as well. Saying that both are object oriented is like saying Spanish and Italian both are members of the Romanic language family.
Of course, all of this is irrelevant. Most probably, your underlying question is whether it's "worth" learning Ruby instead of or in addition to Java. Unfortunately, there's no easy answer to that either. You have to weigh advantages and disadvantages with each language, such as popularity, demand and career opportunities. And then there's naturally the question of which language you prefer. You might like one language more than the other simply because it has a nicer syntax. (Similarly, you may prefer Italian because you think it's more "beautiful" than Spanish, even though the latter is more widespread and you'd have more "use" for it.)
Personally, I prefer Ruby. For many different reasons. Just like I prefer Italian.

The Object Oriented feature in Ruby is actually very different compared to Java.
In Ruby, everything is an object, including a primitive type (in Java) like integer.
In Ruby, new is like a property instead of a keyword. So to instantiate an object you would do this in Ruby:
animal = Animal.new
Ruby is strong typing but also dynamic. Because of its dynamicsm, Ruby enables you to do duck typing.
Ruby's answer to multiple inheritance is mixin (which is a language feature), where in Java you would implement many interfaces.
Ruby has got block, where you would use anonymous class to achieve the same thing in Java. But IMHO Ruby block is more powerful.
So I can say there's not too much similarities in Java and Ruby. Until today I can't find any similarities between the two as Ruby has gone its own path unlike many other language that derives from C language.

Getters on an immutable type [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 months ago.
Improve this question
I am writing some immutable types in Java and wonder about how to name the accessor methods.
The Java Bean specification says that the names of accessors should be getX or isX, but since the fields are final, there is no setter and the fields are more like attributes than properties.
There for I'd prefer naming the getter methods like:
public T x()
rather than
public T getX()
Please note as an example:
public int java.lang.String#length()
(Which might have been specified so early in the Java history, so the conventions where not there yet.)
The immutable objects expose means to create modified versions of themselves through methods which I've tried to name like a verb rather than MyObject MyObject#setX(), this should limit the risk of the user calling setX() and think that the object has changed. So: MyObject MyObject#shine(newShineLevel).
This is not always possible easy though. How would you name a method for adjusting an endpoint in a rectangle other than Rectangle.setUpperLeft()? Rectangle.adjustUpperLeft maybe, but now we're just moving away from the conventions.
I guess the question is relevant for all languages, but this questions concern Java in particular.

If these classes may be used with any reflection based framework then you are better off staying with the getX convention. For example, accessing properties in JSPs and other templating systems via an expression "x.y" requires that the object have a method getY().

In my opinion, the get prefix is really only mandatory if you're writing a bean. There are lots of examples of where get is not used. not only String.length(). You find it in the primitive wrapper classes (intValue(), doubleValue(), booleanValue(), ...), enums (name() and ordinal()) and collections (size()), and the way annotations were design also seems to encourage the get-less style. (Josh Bloch covers the subject in Effective Java, and advocates the more readable get-less style unless you're actually writing a bean.)
So: Use the get prefix and your object can be used as a bean. Ditch it, and your code gets easier to read. It's up to you to decide what you think is more important.

Even for immutable types, the convention getX() still stands. Some examples:
java.lang.Integer.getInteger()
java.lang.Boolean.getBoolean()
It is true that there are also many examples such as java.lang.String.length(), but the common convention is to use getX. Just as mentioned in the answer below, it is crucial to separate between an atomic get operation, and a method which does some calculations on the data.
Also worth mentioning that plain java beans in many frameworks depend on the fact that getters/setters are conveniently named getX and setX.

The convention in Java for accessing properties of a class -- including immutable classes -- is to use the get and set prefixes so I would recommend using public final T getX().
The reason the length() method on a String isn't called getLength() is because there is no property called length on the String class.

I'd stick with the "get" convention simply because so many other tools work with it. Jakara Commons BeanUtils for example. Lots of tools/libraries will work by default if you have the right naming, but require configuration if you've deviated from the bean accessors convention.
I'm not disagreeing with you reasoning for deviating, I just think you're probably better off in the long run sticking with the get/set convention.

It's a good idea to use get--never mandatory, but people will automatically know what it's for.
Get does not imply that you have that as a member variable, in fact it's supposed to hide that fact. It can easily be giving access to a computed value.
size(), length(), etc were created before Borland found they needed the get/set concept to implement their GUI builder (I'm not sure exactly who came up with the idea, but that was the reason).
intValue, doubleValue etc are not getters, they are converters and therefore are named differently.
Now, all that said, if you really want to use x or getX it is your choice. getters and setters are no longer needed for most decent toolsets, they will use annotations instead--just be ready for a few people to take a few extra seconds typing "get" followed by "ctrl-space" and not finding what they are after.