Revision as of 06:36, 16 July 2015

Development Rules (Talk)

• NAME-06
  • Patrick: according to me, the name must be understable. I dislike acronyms concatenations and abbreviations.

An exception has been done for gmfdiag

• NAME-22

Patrick: I have the same point of view as Cedric, for boolean variable I prefer a prefix with is Celine: this rule as been done because when you create a boolean attribute (available) and ask to automatically generate getter and setter, then a method isAvailable is automatically created. If you create an attribute isAvailable, then a method called isIsAvailable would be created.

globally for all presentation rules, i think that is to strict.

• PRES-01
  • Patrick: I prefer not to be so strict in the structuration of the code. In IDE, now you can order properties, operations as you want (alphabetic...)

Nevertheless: On remarks about inner class. I do like it. I someone add a ne inner class, it has to write a solid argumentation (if no a lot od developper will write the code in one files ;D )

• • Celine: the purpouse of those rules is to make the code homogeneous, and if someone reads a class it will be clearer if all classes are organized the same way. By the way, the order listed here are mostly followed already.

• PRES-10
  • Patrick: 250 characters is better, screens are greaters than in the past.
  • Celine: I Agree

• PRES-16
  • Patrick: as Cedric I prefer in the same line
  • Celine: both approaches have pros and cons, as I worked with both standards, I found clearer when the extends, implements and throws are on a new line (but this is only my opinion ;) )

• PRES-18
  • Patrick: Interesting, but I do know if it can be applicable to papyrus: the code that has been generated is greater than 2000 lines of code per files in some classes.
  • Celine: Rules may not be applicable for generated codes. But they're specially done for developpers.I think it is possible to unplug the checks on the generated files.
• TIPS-13
  • Patrick: Why? I use an Interface of define constants of stereotype names.
  • Celine: This is not the role of an Interface, an interface is a contract.

• TIPS-17:
  • Patrick: I thanks that is more important is to make a good java doc.

explains that a parameter and the returns can be null Explains that the level of complexity n2 n3 or log n. if if is n3 or n4, we know the prerimeter to improve the performance. We have not to forget first we need fucntionality and then we can improve. It s better when the algo is efficient, but it is important to be not so strict to make review from all contributors.

• • Celine: this is mainly for maintainability and to make the method easily undertstandable.

• TIPs-24-29
  • Patrick: I think it is to restrictive
  • Celine : Those rules are mainly to avoid minstakes. Or to define a standard for homogeneity.

• TIPs-30
  • Patrick: the super class in the method must verify when it is possible. How to test it? the problem is imlicit contract, it must be written in java doc.

• TIPS-33
  • Patrick: I do not like, when i write the code, I use a contract approach, I return by taking account contract and then I write my algorithm, In this manner the code is readible and I avoid a lot of indentation.

• TIP-35:
  • Patrick: I do not like it, I find it no readable.
  • Celine: this shortcut is understood by most of the people, and again it is a way to make the code homogeneous.

• TIP-68:
  • Patrick: the use of static has implication. So static use must be motivated and not use it when is possible

• TIP-73:
  • Patrick: Recursive algorithm can be powerfull. I depends the code is made.
  • Celine: I Agree

• COMM-06
  • Patrick: the contributor is already written in the header, so it is not usefull to add it in the javadoc of the file.

I thinks that the version is not usefull, the version is managed by a git.

• • Céline: Most of time the header contains "CEA List" no the name of the autor itself. So either the effective name of the developper has to be written in the header, or into the class javaDoc.

• COMM-07:
  • Patrick: Here you write the contract, in math

you have to write if the parameter can be null if it is possible inform about the complexity of the algorithm n2 n3 logn

• COMM-12
  • Patrick : no! conter example if you apply a sort on a structure, you can explain in 3 lines you your contract and then you explain which algo you implments or resue
  • Céline: this is an estimation from Sonar. This is a Benchmark that defines if a code is properly documented. By experience, it is easy to reach with header, javadoc and inlines comments.

• ARCH-08
  • Patrick: where I put my developper doc (my model etc..). This is developper doc so I must be in the plugin not in the separate plugin to avoid that develooper forgot to modify it.

When he sees the model in the plugin they cannot foget it.

• • Céline: I agree with the fact that we needs to make the documentation homogeneous as well as the code. Because for the moment there are pieces of information on Wiki, user Guide, Plugins, mails, YouTube, ... I think we should define a standard location for all documentations.
• ARCH-12
  • Céline: The string externalisation is already in place, but most of the string are not placed into a specific file: messages.properties.

I don't know if this could be done in Papyrus for the warnings, labels or other text messages.

• SONAR
  • Francois: Why not activate the sonar instance for our project?: https://wiki.eclipse.org/Sonar