Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [esf-dev] Considerations about Coding Rules

Hi everybody

Today, Jonathan and me we discussed about the coding rules, particularly these points.

In short…

1-
     [NAME-17] The first letter of a variable name is normalised to represent its visibility.
IN DISCUSSION

2 -  [PRES-13] The cases of a switch instruction are located at the same indentation level than the switch
No!

Changed by:
switch ...
case :
    int v = 0;
    break;
...


3 -
  [PRES-16] The declarations extends, implements and throws must be located on a separated line, indented as the body of the related Class or method.
OK!

4 -
[PRES-19] A single empty line must be inserted: Between a method declaration and its first instruction.
Removed!

5 -
[PRES-19] Two empty lines must be inserted: Between the different sections of a source file (declaration section, properties section, methods section, etc.).
Removed!

6 -  [PRES-25] A space must be inserted after a cast instruction.
OK!

7 -
  [TIPS-33] A method must contain at most one return instruction.
Changed! Now it is a recommendation. For the “defensive code” (e.g. it is NULL) you should use the” specific exceptions” instead of the “return”.  

8 -
[ARCH-10] The utilization of “re-export”.

OK! But among the internal plug-ins.

9 - [ARCH-13] EMFPluging
OK!

Regards,

Yupanqui



Le 27/08/2015 16:16, MUNOZ JULHO Yupanqui a écrit :

Hi everybody,

 

I have some considerations to do about the coding rules:

 

1-     [NAME-17] The first letter of a variable name is normalised to represent its visibility.

For me it is not necessary, because the Eclipse editor shows to users automatically the different among the variable’s kinds. And another reason is that the prefix are used by classes, like “E” by ECore, “S” by ESF, etc. Consequently if I define a static variable of type “SBlock”, I shall define like “sSBlock”. I think it can create a little bit of confusion.

2-     [PRES-13] The cases of a switch instruction are located at the same indentation level than the switch

I don’t like. This rule is opposite to the current practices, isn’t?

3-     [PRES-16] The declarations extends, implements and throws must be located on a separated line, indented as the body of the related Class or method.

This rule creates unnecessarily line. Nowadays, the users  frequently own the wide screen ( I think).

4-     [PRES-19] A single empty line must be inserted: Between a method declaration and its first instruction.

This rules creates unnecessarily line.

Jonathan, I see you code and, if I understand this rule, you don’t use it.

5-     [PRES-19] Two empty lines must be inserted: Between the different sections of a source file (declaration section, properties section, methods section, etc.).

I think that added comments can do better this job. Add two empty lines can create unnecessarily complexity.

6-     [PRES-25] A space must be inserted after a cast instruction.

I don’t like. This rule is opposite to the current practices, isn’t?

7-     [TIPS-33] A method must contain at most one return instruction.

I don’t agree! In a method with numerous lines, it is more easy to identify a return in the middle of the method and not be forced read all lines for following a variable, because I don’t sure if it may be modified.

8-     [ARCH-10] The utilization of “re-export”.

I don’t have the experience to use re-export. But I think that it can create problems. For example, B depends of A, and C depends of B and A. In this case, if I set re-export A in B. When I  set the dependencies of C, I don’t need set A. Consequently, it is not clear that C depends of A. And if A change, what are the consequences?

9-     [ARCH-13] EMFPluging

Why not AbstractUIPlugin proposed automatically by Eclipse ?  

 

 

Best regards,

 

Yupanqui




_______________________________________________
esf-dev mailing list
esf-dev@xxxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://polarsys.org/mailman/listinfo/esf-dev

 


Back to the top