JDK-6939278 : Drop code convention to follow casts by blank space
  • Type: Enhancement
  • Component: docs
  • Sub-Component: guides
  • Affected Version: 7
  • Priority: P5
  • Status: Resolved
  • Resolution: Won't Fix
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2010-03-30
  • Updated: 2016-07-07
  • Resolved: 2016-07-07
Description
A DESCRIPTION OF THE PROBLEM :
Drop code convention to follow casts by blank space

In the "Code Conventions for the JavaTM Programming Language", At 8.2 there is the advice, that casts should be followed by a blank space.
  Justification:
- Cast is a one-operand operator like - -- ++, so should better be joined to it's value/expression.
- The above mentioned rule is rarely accepted and used, even in Sun's JDK code base.

Difficult to make progress on maintaining JDK code conventions.

URL OF FAULTY DOCUMENTATION :
http://java.sun.com/docs/codeconv/html/CodeConventions.doc7.html#682
Comments
The above justification contains a mostly-false analogy of cast with an "operator like - -- ++". Differences of cast include: - Casts are defined in the JLS in their own section, 15.16 Cast Expressions, distinct from 15.15 Unary Operators - JLS 3.12 lists all operators and cast is not among them. - The syntax of a cast has arbitrarily many tokens (including a type expression), and may include internal spaces (as Map<?, ?>); unary operators do not contain spaces, and so never require neighboring spaces to maintain their visual integrity. - Typical casts are much wider than operators (at least 3 characters '(T)' but usually longer like '(String)'), so there is more need of neighboring spaces to set them apart. Type expressions vary widely in structure and complexity. The type expression in the parentheses of a cast is often better laid out like the LHS of a binary operation. (Small or familiar type names like float, int, String can probably be read easily with or without the extra space.) If we need a "one size fits all" solution, treating casts like binary expressions is closer to the mark than treating them like unary expressions. But, I would prefer to leave the visual layout of casts to programmer taste or more local conventions. I guess that makes me agree with this bug, but not on the grounds stated. Personally, I would oppose *requiring* the *absence* of a space after every cast.
23-04-2013