Best Java practice. Is a declaration constructor before class variables bad?

Question

I'm starting a “static” walkthrough of Java code from a colleague (another student)

It makes no sense to me; reading from top to bottom, these "component" objects are created (and later used in the constructor) before they are declared. But the code happily compiles and runs. Is this a bad practice?

Public Class theObject { private static final long aVariable = 123123123123123; public theObject(...){ componentOne = new Component(...); componentTwo = new Component(...); ... ... componentOne.doSomething(...); } private Component componentOne; private Component componentTwo; } 

Answer 1

Sun Microsystems (now adopted by Oracle) published the Java Coding Style Guide in 1998, in which they recommended specific organization to the declaration class:

• Static variable field declarations
• Instance Variable Field Declarations
• Static initializer
• Static member inner class declarations [*]
• Static Method Declarations
• Instance initializer
• Instance Designer Declarations
• Instance member inner class declarations [*]
• Instance method declaration

Note that this places data declarations at the top of the file. (An previously published Sun publication from 1997 did not cover everything in the above list.) The only important ordering is the static fields inside the field instance, and then only if the fields contain initializers related to other fields. You cannot use a field in an initializer before initializing it. Similarly, an initializer (element 3 or 6) cannot pass a direct reference to a field, except for the purpose of the assignment. (For more information on such direct links, see Java Language Specification, Section 8.3.3 ). As far as I know, nothing more about order matters.

[*] The terminology in the above list (which is literally from the 1998 manual) is deprecated with respect to items 4 and 8. In particular, from the Java tutorial on nested classes :

Terminology: Nested classes are divided into two categories: static and non-static. Nested classes declared static are called static nested classes. Non-static nested classes are called inner classes.

In modern usage, there is no such thing as a "static member inner class."

Answer 2

There is no real consensus on this. Most people will declare class variables at the top of the class implementation, followed by methods, but this is not a requirement. Some books, such as Code Complete, suggest declaring variables as close as possible to their first use. This helps keep the scope of the variable to a minimum.

Answer 3

No, they are not created until announced. The initialization order is fixed in Java, and it does not matter where in the code you place your declarations and constructors.

As for the agreement, it really depends on what you are comfortable with. Although the truth is that the convention is to announce applications first, and then designers, your approach is as effective as any other, if it does not contradict your nature or company rules.

In addition, much more dangerous material is added to the code, which makes it less readable, for example, single-letter variables or the widespread use of less common structures (for example, a three-dimensional operator for complex conditions). Organizing your code is one of the least troubles, as any decent IDE can reorganize your code with whatever settings you place there.

Answer 4

General declaration order in java, (Ref: Java Coding Style Guide )

  public class DeclarationOrder { // Class (static) variables public static int publicClassVariable; protected static int protectedClassVariable; static int defaultClassVariable; private static int privateClassVariable; // Instance variables public int publicInstanceVariable; protected int protectedInstanceVariable; int defaultInstanceVariable; private int privateInstanceVariable; // Constructors public DeclarationOrder() { // Public Constructor } protected DeclarationOrder(int var) { // Protected Constructor } DeclarationOrder(String var) { // Default Constructor } private DeclarationOrder(Double var) { // private Constructor } // Class (static) Methods public static void publicClassMethod(){} protected static void protectedStaticMethod(){} static void defaultStaticMethod() {} private static void privateStaticMethod(){} // Instance Methods public void publicInstaceMethod() {} protected void protectedInstanceMethod() {} void defaultInstanceMethod() {} private void privateInstanceMethod() {} } 

The order in each set should be

• Public
• Protected
• Package Level (without access modifier)
• Private

Answer 5

The order in which class members (methods, attributes) are declared does not matter. By convention, it usually declares all attributes and constants first, then the methods.

For example, in your code: you can initialize attributes in the constructor and then declare the attributes simply because when the class compiles, all attribute declarations will be taken into account, and later, when the constructor is actually called, the attributes will be found. Note that during compilation, attributes in the constructor are not processed, therefore they do not create an error; they only get access at run time.

Answer 6

This is contrary to normal conventions and (as such) makes the code less readable for people who expect normal conventions to be respected ... i.e. most Java programmers.

On the other hand, if the code does this sequentially, and it follows the agreed local coding convention, then readers will get used to it.

So, the answer to the question: "Is this a bad practice?" is that it depends on your agreed coding agreement and what it says about it.

But the meta-answer is that reviewing the code without an agreed coding agreement is a really bad idea. If there is no coding agreement, there is no objective basis for viewing code style. You may get a bad result.

Answer 7

The main specification of the Java language defines in sections 8.1.1, 8.3.1 and 8.4.3 the following streams that we must use:

• public
• protected
• private
• abstract
• static
• the ultimate
• transitional
• volatile
• synchronized
• native
• strictfp

We should use this order when writing Java code;)

Java Language Spec Reference