Bonjour ! Petite question toute bête. En effet, dans un petit programme en D je suis amené à faire une décraration vide. Si j'utilise le style d'indentation Allman, est-il mieux de rédiger comme ceci :

statement {}

Ou plutôt comme ça :

statement
{
}

Merci d'avance de l'aide que vous pourriez m'apporter

Avec le deuxième, on comprend clairement que ton statement est vide au premier coup d'oeil.
Et si jamais tu dois mettre des instructions dedans, t'auras juste à insérer tes lignes à l'intérieur, alors que dans le premier cas tu dois réindenter le tout.

C'est ce que je me disais aussi et c'est ce pourquoi j'ai opté, pour plus de lisibilité quitte à rajouter des lignes. Merci !

De toute façon si t'es en C/D/CPP/Foo-à-accolades t'es certainement dans un langage avec de longues structures de contrôles, de définition et un typage statique. Donc t'auras forcément beaucoup de lignes pour pas dire grand chose, alors t'as aucun intérêt à tenter de compresser ton code comme on pourrait le faire en Python ou en Ruby. T'as déjà du code long à cause du langage, alors faut tout faire pour le rendre plus lisible, peu importe si ça augmente le nombre de lignes (enfin faut pas pousser non plus et faire 8 espaces par niveau d'indent et sauter 3 lignes entre chaque instruction)

"Avec le deuxième, on comprend clairement que ton statement est vide au premier coup d'oeil."

Justement, j'trouve ça plus clair dans le 1er cas, dans le deuxième j'ai plus l'impression qu'il voulait mettre quelque chose dedans mais qu'il a oublié, alors que dans le 1er on voit bien que c'est intentionnel si c'est vide

statement
{
// y'a rien là c'est normal j'ai rien oublié !
}

LEpigeon888 > quand on relis du code de quelqu'un d'autre, je pense qu'on peut partir du principe qu'il n'est ni stupide, ni qu'il a oublié la moitié de ses instructions.
C'est peut-être le cas, mais si on commence déjà par le considérer on ne peut plus rien croire

@Caletlog : as-tu déjà repris de l'existant ? Une application avec au moins un an d'existence et de MaJ successives et des roulements de développeurs ?
Il y a énormément d'aberrations de ce genre pour des raisons plus ou moins compréhensibles.

Perso, quand y'a un bloc volontairement vide, je préfère nettement voir un commentaire à côté expliquant la raison (même si c'est juste un simple "do nothing") histoire de savoir ce que le développeur avait en tête avait en tête. Le code est parfois assez difficilement compréhensible, si l'on pouvait un peu se passer de la case "psychologie" pour tenter de comprendre ce que l'écrivain avait en tête, on gagnerait du temps.

Non, j'ai pas encore eu la chance (?) de bosser sur quelque chose de 'gros'.

Mais je suis tout à fait d'accord avec ce que tu dis, et je pensais pas avoir affirmé le contraire. Je voulais juste dire que si on partait du principe qu'à chaque bloc vide on devait se demander si le développeur avait pas oublié quelque chose, on s'en sortirait pas.

Les blocs vides vraiment involontaires/erreurs, c'est si fréquent dans le monde réel ?

@Caletlog : "Les blocs vides vraiment involontaires/erreurs, c'est si fréquent dans le monde réel ? "

Heureusement non
Ce n'est pas fréquent, mais ce n'est pas forcément rare. L'exemple en question (bloc vide) n'est pas forcément parlant, mais ça peut être utilisé pour de l'initialisation statique ou forcer un cycle de vie particulier... ou tout autre raison qui ne me viennent pas à l'esprit présentement et qui ont l'air tout sauf logique (ou très propre à un contexte en particulier).

Par contre, des machins WTF-esque comme la réécriture complète d'une API de gestion de date alors que la built-in fonctionne très bien, ou des variables ré-utilisées à outrance, ou des globales avec N significations, ça par contre, ça se rencontrera plus fréquemment.
Dans ce cas, tests unitaires, outils de refactoring et programmation défensive sont de circonstances.

"Les blocs vides vraiment involontaires/erreurs, c'est si fréquent dans le monde réel ? "

Comme ça, je vois un exemple typique de bloc vide par erreur : le try catch d'une exception sans gestion de l'exception. Ces blocs peuvent être volontaires (mais dans ce cas-là il faut commenter pour l'expliquer), mais dans d'autres cas certains mettent un catch d'une exception en se disant "de toute façon elle ne peut pas être lancée ici". Dès fois c'est possible de partir de se principe là, mais dans d'autres cas c'est une erreur de raisonnement, et un jour on se retrouve avec une exception lancée, non gérée, non loggée, et un comportement inattendu.