Talk:Eiffel Coding Standard
--Ericb 08:25, 21 July 2009 (UTC): I always wondered why classes formatted by EiffelStudio have such formatting inconsistency: keywords at the top level are sometimes followed by an empty line (e.g. 'feature') and sometimes not (e.g. 'inherit', 'create'). In Gobo the formatting is consistent regardless of which top level construct of the class: all top level keywords are followed by an empty line.
--Peter gummer 01:06, 22 July 2009 (UTC) I've never considered this an inconsistency, Eric. EiffelStudio never puts an empty line after a top-level keyword, except after 'feature'. The reason for this exception looks obvious to my eyes: there is always one empty line above and below each feature. In other words, it's not really an exception to the rule at all, because the features do commence on the line immediately after the keyword 'feature'; the empty line is actually part of the list of features. This certainly looks more right to my eyes than the Gobo style of formatting.
- --manus 16:57, 22 July 2009 (UTC): This is exactly why I came up with this guideline but it was already there before I came to ISE in 1996 and this was all done in the WEL library (I've checked the code included in EiffelBench 3.3.9).
---Ericb 08:23, 22 July 2009 (UTC): For me, the list of features is separated by empty lines. In the same way the list of creation procedure names is separated by a comma. We don't put a comma before the first creation procedure name nor after the last one. A feature by itself does not have an empty line above and below it. Otherwise two consecutive features would be separated by two empty lines, not just one. Furthermore, why is there no empty line before the creation procedure names but there is one after? I can understand that you prefer the formatting rules of EiffelStudio, especially if you are used to it. I used the formatting rules in Gobo before those of EiffelStudio were enforced, and I still prefer those used in Gobo. Of course, as often with formatting rules, this is a question of taste. But I surely don't agree with you: there is an inconsistency in EiffelStudio's formatting rules. You can call it an exception if you want. You may like this exception. But this is not consistent.
- --manus 16:57, 22 July 2009 (UTC): As long as our code is consistent with what we said, I think that makes our code consistent.
- --Ericb 07:40, 23 July 2009 (UTC): I didn't mean to say that your code was not consistent with your rule. I said that some parts of your rule are not consistent with some others.