Java Magazine, Sept/Oct 2016

ORACLE COM JAVAMAGAZINE SEPTEMBER OCTOBER 2016 05 from the editor location of opening braces size of indents tabs vs spaces how to stagger or not stagger if else sequences Javadocs numerous formatting options and so forth Obviously this would apply to higher level concerns as well fully expanded imports vs wildcards the sequence of import statements and variable declarations and so on By having a fixed set of guidelines every Java listing would be consistent and not require reexamination to adjust to a given individuals or sites style Curiously enough in a certain way Javas initial appearance on the scene addressed what at the time was a tremendous laxity in language that made some tasks exceedingly tedious The principal language before Java was C It was purposely designed from a radically nonprescriptive perspective Even today after many rounds of standardization C has numerous places where behavior is undefined or left up to the implementation to define In the mid 90s when Java first appeared C was far looser An integer could be more or less anything the compiler defined it to be with if I recall correctly a minimum of 16 bits of width 16 32 and 64 bits were all legitimate implementations of an integer As a result porting C from one platform to another was extraordinarily tedious Java solved these problems Data items had fixed sizes across platforms and code could be run on multiple platforms without modification Cs lack of standardization caused so much pointless activity that when the original team from AT T Bell Labs developed a new language Go they chose a highly prescriptive implementation There is one formalized coding style for Go and all code is expected to use that style A code formatter is bundled with the Go distribution In the language itself there are additional constraints For example the executable code after any if statement must be enclosed in braces even it if contains only a single line Many other conventional items are defined by what is known as idiomatic Go The happy result is that all Go code looks the same Reading and writing it is easy The lack of standardization of details during the last few years has been an issue in Java in small but annoying ways beyond command line syntax For example the three variants of the annotation for indicating a field should not be null @ NonNull @ Nonnull and @ NotNull The first of these was used by Checkstyle and FindBugs the last of them by Java EE 6 and the IntelliJ IDE The result was that if you coded in one environment and moved to a different development environment you had to change your code or your toolchain to get your expected level of nullchecking This is of course the exact antithesis of Javas vaunted portability when switching IDEs is enough to make code behave differently Fortunately Java 8 s use of the Checker framework has now consolidated the convention around @ NonNull The convenience and benefits of such strictures that ensure uniform syntax are widely recognized This is evident in the choice of most modern development organizations to prescribe their own house style for code which is frequently enforced in code reviews so that all developers use the same conventions But these styles conflict with each other for lack of a single unified set of conventions If the world were all Java I think it would not be too onerous to put up with the diferences although the time lost in doing so is lost for no good reason But in an increasingly polyglot world in which other languages JavaScript HTML and so on play significant roles the lack of enforced coding standards in Java and especially across those languages combine to create a sustained and pointless drag on productivity Andrew Binstock Editor in Chief javamag_ us@ oracle com @ platypusguy Most modern development organizations prescribe their own house style for code which is frequently enforced in code reviews But these styles conflict with each other for lack of a single unified set of conventions Coming in November our special issue on JUnit 5