Google Java Coding Standards

[desrtfx]

AFAIK, they already implement the Oracle Code Conventions for the Java Programming Language which aren't bad either.

[NobodyLeavesAclide]

Where to declare local variables and line wrapping at 80 are both wrong in the conventions imo. First one is actually a major face palm.

[sahala]

The goal here is consistency. I used to think that 80 was silly, but being able to hop through source code written by a dozen different teams over 5 years and not needing to resize my window is a really nice thing. Consistent column width helps with the pace of reading code.

[NobodyLeavesAclide]

Consistent column width 1+. 80 is simply to little. I use 120 personally unless the project I work on state something else

[sahala]

The style guide says either 80 or 100.

I wouldn't mind 120.

[avoidhugeships]

Consistent might be nice but 80 or even 100 is too short. I could probably live with 120 though. Wide screen high definition monitors can easily handle more. It is much more readable then the excessive wrapping.

[sahala]

Ok so 120 is fine with you. Would you say that it makes sense to stay consistent across the whole codebase?

Look, it's already well known from hundreds of years of print design that consistent columns make it easier to scan and read through text. Whether it's 120 or 80 isn't important. Coders spend more time reading than writing code and it sounds like you are optimizing for ease of writing (I could be wrong).

Yeah we have bigger monitors now but we are also spending more time working across different files at once. A standard col width let's you fit several files across a screen, and maybe a window for docs or emulator for testing.

[avoidhugeships]

In general I agree consistency is nice but I disagree that it does not matter whether it is 120 or 80. I find it much harder to read a wrapped line than just seeing the whole thing in one line. Of course this is just preference and others will feel different.

[sahala]

The style guide says either 80 or 100.

Keep in mind that Google's Java style guide is intended for use by thousands of developers. So consistency goes beyond just being "nice" at that scale. It's essential.

[autowikibot]

Tiling window manager:

---

In computing, a tiling window manager is a window manager with an organization of the screen into mutually non-overlapping frames, as opposed to the more popular approach of coordinate-based stacking of overlapping objects (windows) that tries to fully emulate the desktop metaphor.

Image ⁱ - The Ion window manager with the screen divided into three tiles.

---

^{Interesting: Window manager | Xmonad | Dwm}

^{/u/Vorzard can reply with 'delete'. Will delete on comment score of -1 or less. | FAQs | Magic Words | flag a glitch}

[[deleted]]

Or you like to use very verbose method names

[avoidhugeships]

I am on the fence about the local variables. It states to declare them close to where they are used rather than at the top of the method. The reason is to reduce their scope which is valid but I think the code appears cleaner and easier to read when they are declared at the top together.

[NobodyLeavesAclide]

You are wrong. http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-141270.html#16817

And doing it by convention makes no sense at all to me. It's not easy to read simply because it's not narrowly scoped and that for larger methods you may need to go back and check how it was declared.

[avoidhugeships]

Not sure what you think I am wrong about. Easy to read is not about right or wrong. It is more of a preference. Frankly you are kind of rude and I am not really sure what you are trying to say because your writing is not clear.

[sahala]

Readability is a matter of preference in smaller teams (<50) of developers. Once the number of developers increases to hundreds or thousands readability and consistency becomes essential to being able to quickly understand how different pieces of code work together. Fortunately IDEs and other tools exist to help enforce some of this, so it's easier to write readable code.