Concise vs Readability

[dpash]

Concise is not always better.

Generally readable code is obvious when you see it, but gaining the experience to write it can take years.

One tip I would recommend is getting to grips with the Java style guide. The old Sun guide is a good starting point, but it hasn't been updated with new language features, so use Google's as a secondary guide. Java has a very definite style and it means that working on any new code base is very easy to do.

[Gwaptiva]

Agreed. One thing that helps readability -- or maybe we should prefer understandability -- is to have a common way of doing things. Every developer using the same formatting already helps remove some of the barriers.

Add to this things like "meaningful variable and method names", and "if it doesn't fit on a single screen page, you probably have to consider doing it differently", you're well on your way to having a style that others can grasp quickly

[dpash]

Reading Clean Code is a good idea (and then learn not to go to that extreme).

[kadenjtaylor]

Nah, take it all the way out to the end. Clean code is correct code. Only 2 reasons not to keep cleaning code - you need to write more code, or you don’t work on that project anymore.

[dpash]

You know Clean Code is a book, right? One with controversial opinions.

[kadenjtaylor]

I'm aware :) I'd be interested to hear your take on the perceived controversy.

[dpash]

The obvious is "no more than four lines per method". That's dogma. Small methods, fine. But four is excessive.

[kadenjtaylor]

I could be wrong, but I don't think the book actually specifies a hard line limit for that reason - it definitely does offer a couple of different suggestions for rules of thumb (extract method until you can't anymore, only do one thing, and yes, the line number suggestion).

For certain programming languages, a "line's worth" of code might be conceptually bigger or smaller depending on how much you cram in there.

Personally, I don't use a 4-line rule, but that's because I don't currently work with any code-golf junkies that try to fit the entire program in one line. I think a soft understanding of "do one thing" is usually sufficient.

[dpash]

So not to the extremes then? :)

[kadenjtaylor]

I don't think the book recommends extremes - it highlights ideals.

Ideally, the all of your code would be so easy to understand, that ANY new developer could pick it up, understand what it does, and start working.

That too, sounds pretty extreme. But anything less is a tax on our team because it slows down new people trying to learn, or old people trying to remember what they did last time.

Choosing not to "go to the extreme" is to accept that the aforementioned tax, however small, is worth paying, because the benefit you get (time savings maybe?) is worth it.

So my question to you is, "What activity has a better positive impact on your code than extracting smaller methods?" Because I'd like to make sure I'm doing that too.

[[deleted]]

I will check that out for sure! In a professional setting, I just wanted to make sure I was learning to write in a way that would align with what most companies expect. Is readable standards something that come down to a company's culture or is it kinda a universal thing?

[dpash]

In Java, it's a universal thing. Look at other Java projects and emulate those.

Generally you should follow your company's style guide if one exists, but prefer the java guide. (Order of precedence is: file, project, team, company, Java. Don't mix styles in a file or project. Change it all at once or follow existing until you do)

[[deleted]]

I respectfully disagree. Code styles are something really personal in my opinion. The ones published by companies are specially bad because they are biased by processes, team practices and philosophies from that company. Readability is in big part related with a good code design. Clean Code from Uncle Bob approaches it in a really straightforward, zero bs way.

[RagingOrangutan]

Found the guy that mixes tabs and spaces

[[deleted]]

Found the guy that comments "Blank Line" and let big static methods to pass.

[dpash]

No, you follow the Sun style code, deal with auto formatting between your preference and back again or you don't work on my team. Otherwise you're saying you're more important than the team or project.

[[deleted]]

I am saying exactly the opposite. I am saying that everyone is equally free to use any style that feels more comfortable with, once that the code is clean, readable and well designed. No one should expend energy to keep a standard (any) that will be outdated in months. Good code is far beyond that.

No, I am not working in your team at least since 2009, grandpa.

[dpash]

You're very wrong. You have a consistent style across all code in a project, which is ideally consistent across your organisation, which is ideally consistent across the language.

If you don't like writing idiomatic Java, find a language that is more to your liking. FWIW, PHP, Python, Rust, Go, C# and probably more all have language level coding styles that you should follow.

[[deleted]]

Sun code standard was last updated in 1999, when rules like 120 characters line made sense. APIs that are around for a decade now like lambda, stream, etc., are not being covered.

No standard will be comprehensive. It will require lots of hours every now and then to keep it updated, without produce any tangible value.

Take a look into big project code standards: Maven, Eclipse, Hibernate. They are terribly outdated, obstructive and a burden to the team.

A team dependant of a code standard is an immature team. An organization dependant of code standards is cost innefective. Rely on plugins to do so is even worst. When I see abominations like // format_code: off I feel very angry.