[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [ee4j-community] EE4J code conventions?
|
-1 to enforcing code style
+1 to monitoring code quality and even enforce some metrics (e.g. method length)
Style is a matter of taste and I've never saw that enforcing it really worked. Rarely it improves the code readability and often slows everybody down with a lot of broken builds just because of a bracket on a different line.
If qe decide to enforce style, then absolute basics which bring the most value (e.g. no tabs but spaces, no if statements without brackets, etc)
Code quality is more important for keeping the code readable and maintainable but I would also enforce only a handful of basic and most important rules.
Ondro
From: ee4j-community-bounces@xxxxxxxxxxx <ee4j-community-bounces@xxxxxxxxxxx> on behalf of Werner Keil <werner.keil@xxxxxxxxx>
Sent: Monday, April 9, 2018 11:17:18 PM
To: EE4J community discussions
Subject: Re: [ee4j-community] EE4J code conventions?
I would say from a point of potential users of Jakarta EE it is far less important if the braces close in the same line, developers use the "Hungarian notation" or not, but a certain level of code quality should be displayed if Multi Billion
Dollar companies are supposed to use and trust it.
As Bill mentioned, OpenJDK failed to implement a common coding guideline. And based on SonarCloud it also failed quite miserable when it comes to code quality and avoiding code smells or technical debt:
https://sonarcloud.io/dashboard?id=openjdk (this was last analyzed in October 2017 shortly after Java 9 went Final)
A
small number of Eclipse projects like Eclipse Collections also uses that public SonarCloud instance: