Utilisateurs de style de serrage de 1Tbs, comment formatez-vous des conditions longues dans un Si code> instruction et le code suivant? p>
for (int relevant_counter_variable_name = START_VALUE;
intelligent_expression_that_may_include_the_counter_variable;
relevant_counter_variable_update) {
first_code_line_inside_the_block();
}
5 Réponses :
Je suis d'accord que les styles de mélange sont souvent fronçés sur. Dans les cas où le style est strictement strong> em> appliqué, (codage d'entreprise)
Mais j'ose dire que lorsque cela est possible, la règle peut être plié pour la lisibilité. P>
Je fais habituellement cela: p> if ( (this_is_the_first_part_of_a_long_condition) &&
(the_second_part_is_shorter__wait_no_it_is_not) &&
(and_one_more_for_the_road)) {
here_comes_the_block_code();
}
if ( (this_is_the_first_part_of_a_long_condition) && (the_second_part_is_shorter__wait_no_it_is_not) && (and_one_more_for_the_road) ) { here_comes_the_block_code(); }
C'est en fait comment j'ai tendance à le faire.
I Lignes continues à double tiret:
if ((this_is_the_first_part_of_a_long_condition) && (the_second_part_is_shorter__wait_no_it_is_not) && (and_one_more_for_the_road)) { here_comes_the_block_code(); }
Indentification de l'espace unique pour chaque niveau, utilisez des parenthèses pour chaque condition qu'il soit nécessaire ou non.
Pour des conditions complexes, les parenthèses de style Allman peuvent bien fonctionner. P>
approche générale fonctionne pour la poursuite du code qui a gagné 'Tjuste sur une ligne ou pour les listes d'arguments de fonction. p>
Chaque élément de fermeture est en retrait au même niveau que l'élément d'ouverture, d'où le "));" Pour "trace.writeline (string.format (" et le freestanding ";" pour "retour". p>
ymmv. p>
Je perdrais simplement quelques variables pour une clarté et une lisibilité absolues: Vous pouvez même donner aux problèmes de noms significatifs, tels que P> < Pré> xxx pré> p> / * * indent-off * * / code> tricherie. P>
C'est exactement le cas où je passe temporairement au style Allman et placez l'attelle d'ouverture sur sa propre ligne alignée sur la corse de fermeture. Il y a ceux qui vont crier et gibber sur "Mélanger des styles", mais je pense que cela fait du code lisible. (La dernière règle du Guide de George Orwell pour effacer l'écriture est de «casser l'une de ces règles plutôt que de dire quelque chose debaright barbare.») Pouvez-vous dire pourquoi vous pensez «ça n'a pas l'air très bien»?
@Libik: Bien que le début du bloc (Brace d'ouverture) ne soit pas vraiment une partie du
si code>, j'aime le fait que Allman le place juste sous le premier caractère du mot clé. Mon œil les met ensemble et le fait très vite. Si la condition s'étend sur plusieurs lignes, le
si code> et le
{ code> est séparé et je peux les entendre pleurer. Sérieusement, cela ne ressemble tout simplement pas aussi évident qu'ils sont dans la même colonne.
Je suis avec Librik ici - il est plus important de rendre le code lisible que de suivre mécaniquement un style. Vous avez trouvé des cas où la "règle" devrait peut-être être considérée comme une recommandation - suivez votre style préféré, sauf quand cela ne fonctionne pas. Personnellement, je suis tout le temps du style Allman, et je n'ai pas rencontré cela. :-)
BTW, votre longue condition peut être corrigée avec un refactoring
si (is_some_condition (x, y, z)) { code> etc.
@Bo: Vous êtes correct sur le refactoring, bien que j'ai généralement des noms de variables assez longs. Ce type de refactoring n'est pas toujours suffisant, par exemple lorsque le
si code> est sur le deuxième niveau d'indentation et j'ai trois conditions avec des noms variables de 15 caractères ou plus.