Add CheckStyle or any code formatter/validator

[fragmatyc]

Use CheckStyle with Sun's conventions. Add "p" as prefix for parameters and "l" (small L) for local variables prefix.

[Cpt-xx]

I'll do it, but I fail to see the added value of prefixing the "p" and "l". I'll send a link to a good piece about Hungarian notation that gives a better suggestion for prefixes. The convention you insist upon does not take java 8 conventions for lambdas into consideration either and I don't see any mention of it in the Sun/Oracle standards for this variation on Hungarian.

The same goes for prefixing "this." for global members, I fail to see the added value there as well.

As said I'll follow this, but expect more protests from others when they want to join. Provide them with a convincing number of reasons. Just "l is for local and 'l' makes that clear, 'p' is for parameter and 'p' expresses that clearly" won't cut the mustard.

[fragmatyc]

Java offers the possibility to add this in front of members to accentuate the definition of the scope. this is optional, but I think it's good to show the scope of a variable. p would tell us to pay attention not to modify the state of the object if we are returning a value and l would tell us it's safe to do so, but we should not return a value (method vs function).

Here, we have two choices. Either we change the code base to remove the prefixes, or we comply to this rule which requires only one additional keystroke to give a bit more information about the scope (not the type, like in the Hungarian notation, eg.: strMyStringVal or intMyIntegerValue).

The difference between the proposed notation and the Hungarian notation is that it does not relate on the same thing. Hungarian is for type, this one is for scope. Java is a strongly typed language, so the Hungarian notation does not make any sense (compilation will fail if we do not comply).

If you are into it, I agree to change the convention. I cannot tell you more argument than: "it just help a bit and does not make it a pain a write". TL;DR; It's more useful than a pain ;)

[Cpt-xx]

Firstly, here is the link I wrote about: article. Read this article (and in particular the latter part, in which the actual intention of the Hungarian notation is explained), and see what Hungarian is actually about. Tip of the vale: it is not about the type str or int, not even l or p, it is about domain and context. I personally do not see the added value, my IDE helps me point out that a variable is local (it highlights it for me) and my compiler helps me ensure that I don't assign a new value to a parameter (by means of 'final').

There are other and better ways of ensuring that a parameter isn't modified, ones which use the compiler to ensure that: 'final'. Both in the parameter declaration and in the object we pass as a parameter. The latter can be done using DTO-like objects which ensure setters aren't present. Also unit tests can help us ensure that no unwanted interactions have taken place. Use a Mockito.mock() object and verifyNoMoreInteractions() or verifyZeroInteractions() tell you if any (unwanted) interactions have taken place. Put down a rule that these unit tests must be in place for all parameters and Bob's your uncle. Don't rely on a developer to not assign a value because he didn't adhere to the rule, use the tools you have to ensure it. Trust is good, checking is better is an old adagio in the project and architecture world.

And we don't have to refactor the code in case we would decide that the 'p' and 'l' rule is abolished, the names in itself are perfectly fine when we follow different rules (the compiler still accepts them). The compiler also will accept stupid statement like "String strString = new String();" just as it would accept "String tempUserName = new String();". It is just that for a human the second statement expresses the scope and possible usage of the parameter just a bit more explicitly. For the compiler both are equal, as they both follow the basic Java naming rules: not a reserved word, not starting with a digit, etc.

I'm not sure I understand your statement ".. but we hould not return a value (method vs function)." Could you expound on that, I want to make sure I react having a correct understanding.

Please do not think by the tone of my writing I am looking for disagreement or a 'religious war', it is just that your arguments have not convinced me.

[fragmatyc]

Hey! I've used both ways of defining variables names. Adding "p" in front of parameters does not make the code more complex to read. There are no more argument than "it helps to see the scope of the variable", the same as there are no more argument against than "my IDE shows it for me". I don't mind using both in any project as it does not make development harder. It's a matter of preference. This project was started using this naming convention and I don't see the benefit of dropping it. On the other hand, I agree that defensive programming is better than conventions.

By "but we would not return a value (method vs function).", I meant to point the difference between a method and a function.

[Cpt-xx]

I'm using the default Sun-java checkstyle rules and I'm getting a bit tired of seeing that checkstyle disagrees with (as per your wish) not providing java-doc with methodsand classes and whining about the fact that my lines exceed 80 positions in length. Are you sure you don't want to adept this style and issue a project-customized version? I'm losing sight on relevant issues with checkstyle this way.