bien la preuve qu'il faut écrire
et nonCode:if(b) ...
ouCode:if(true == b) ...
Code:if(b == true)...
Version imprimable
Exactement, pour moi le problème c'est quand on tente d'appliquer bêtement une convention de codage potentiellement bénéfique et bien adaptée à un langage (voire couple langage/IDE) à un autre où elle n'est plus utile, voire contre-productive, sans se poser les bonnes questions (quelles raisons ont poussé à définir cette règle ? sont elles encore d’actualités ?).
Heu... C'est de l'humour j'espère. Ou alors c'est pas du C.8O
Donc si le retour de fopen (Pointeur convertit en entier) est 0, souci, si le retour de fopen est différent de 0 tout va bien. Et le pointeur ne sera d'ailleurs probablement jamais négatif. En 32 bits, un pointeur est généralement considéré comme un unsigned int dans les comparaison. Donc (pointer >= 0) renvoie toujours vrai sur de nombreux compilos.Citation:
Envoyé par man
Pour moi le code de ton prof est valide, et le tien non. Merci de confirmer ou contester ça.
[edit]
Code de test :
Résultat :Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40 #include <stdio.h> FILE* openInvalidFile() { return NULL; } FILE* openValidFile() { return (FILE*)-12; } int main() { FILE* f; if (f = openValidFile()) printf("Fichier valide ouvert %d\n", f); else puts("Echec de l'ouverture d'un fichier valide"); if (f = openInvalidFile()) printf("Fichier invalide ouvert %d\n", f); else puts("Echec de l'ouverture d'un fichier invalide"); f = openValidFile(); if (f >= 0) printf("Fichier valide ouvert %d\n", f); else puts("Echec de l'ouverture d'un fichier valide"); f = openValidFile(); if (f >= 0) printf("Fichier invalide ouvert %d\n", f); else puts("Echec de l'ouverture d'un fichier invalide"); return 1; }
Fichier valide ouvert -12
Echec de l'ouverture d'un fichier invalide
Fichier valide ouvert -12
Fichier invalide ouvert -12
Ne pas avoir le droit de créer de nouvelle base de donnée pour des activités différentes ! :cry:Citation:
Quelle est la règle de codage la plus étrange que vous avez été forcé de suivre ?
Imaginons par exemple que nous ayons créé une base correspondant à des recettes de cuisine, avec les champs "ingrédients", "durée" et "opérations".
On décide ensuite de créer un planning d'entrainement sportif, du coup, dans ce cas, "ingrédients" correspond à "type d'exercice", "durée" à "lieu" et "opérations" à "équipement". Seulement, comme il manque un champ pour "durée de l'exercice", alors on va utiliser le champ "ingrédients" en séparant la valeur "type d'exercice" et "durée de l'exercice" par un délimiteur arbitraire... :calim2:
Tout cela est parfaitement résumé dans cet article...
> en Java, mettre des getters/setters sur des DTO, et interdire la moindre "intelligence" dans ces getters/setters.
Où est l'intérêt de ce genre de chose, alors qu'il suffit de laisser les attributs public?
Enfin, dans tout les cas il faut écrireet non l'inverse. Peut importe qu'il s'agisse de booléen, d'entiers ou autre. Et très souvent les développeurs écrivent l'inverse.Code:if (maConstante == maVariable)
Après, pour ce qui est de préciser à chaque fois "true" ou "false" quand on compare un booléen, chacun est juge, tant qu'il respecte la règle fixée sur le projet bien évidemment.
Sinon, pour rester sur les booléens, voici une règle qui m'a semblé intéressante sur un précédent projet : Les booléens doivent toujours être écrits pour que la valeur "true" reflète un résultat positif. Par exemple, un booléen peut s'appeler "isConnected" mais pas "isNotConnected".
Et c'est vrai qu'on tombe souvent sur des booléen négatifs dans les projets. Après, je ne pense pas que ce soit vital comme règle, mais ça peut faciliter la lecture du code je pense.
Sur certains outils tels qu'Eclipse, cela ne pose aucun problème de formater tout un projet après coup mais oui, il vaut mieux prévoir cela au début.
La première idée de cette règle me semblerait plutôt de bien montrer que tu as pensé à l'alternative (dans certains domaines ça peut être une question vitale ou extrêmement importante). NOTHING n'est effectivement pas très explicite donc personnellement, quand je l'applique, je m'efforce de mettre un commentaire utile.
Celle-là je la mettrai dans le top 10 moi ;)
Effectivement, les accolades me paraissent vraiment incongrues placées comme ça...
Merci pour le lien wikipedia ;)
Est-elle ou a-t-elle été développeuse sur des projets dans sa vie, ou c'est juste purement arbitraire de sa part ? :)
Bon si ce n'est pas ironique, alors il faudra peut-être un jour que tu te penches sérieusement sur le sujet et peut-être comprendras-tu les raisons de cette phobie des procédures stockées. Il y en a plusieurs...
Certes, la raison doit probablement être qu'il ne faut pas déroger à la règle d'indiquer le booléen que l'on teste mais dans ce cas précis, ça me semble effectivement très moyen, je compatis :).
Sinon, en Java, qu'est-ce vous pensez de l'utilisation d'un label avec un break pour sortir d'une boucle ?
C'est loin d'être clair lorsque l'on rencontre cette notation la première fois mais en ce qui me concerne, je considère que c'est une bonne pratique. C'est encore plus évident lorsque l'on a deux boucles imbriquées et que l'on veut pourvoir en sortir d'un seul coup.Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17 protected boolean isContainingMainFile(File[] files) { boolean isInList = false; String documentFileName = projectName + ".xml"; found: for (File file : files) { if (documentFileName.equals(file.getName())) { isInList = true; break found; } } return isInList; }
Quand j'utilise celle-ci, certaines personnes parviennent à comprendre son intérêt quand je leur explique et d'autres s'en offusquent (bêtement)... CheckStyle, PMD, et les autres ne s'en offusquent pas eux ^^
Oui, ça paraît moyen au premier abord mais la raison est que cela permet de la généricité dans les traitements de ce genre d'objets, notamment par réflexion ou même AOP. Le tout est de ne pas saisir à la main les getters/setters... Ca reste lourd, on est d'accord, faudra faire quelque chose un jour pour rendre cela plus efficace.
Pour ma part, je trouve le K&R totalement incongru.
C'est une mode apparue au début des années 80, liée historiquement aux contraintes de l'éditeur des systèmes Unix de l'époque, qui a eu le bon gout de disparaitre au début des 90' et que j'ai vu avec stupeur réapparaitre principalement chez les codeurs Javascript à la fin des 90' alors que la majorité des dev. C++ et Java ( et C# après) utilisaient le Allman (que pour ma part j'impose sur tous les développement - le refactoring d'aspect de VS permettant de ramener le code des égarés à la raison :mouarf:).
Les choix du type de parenthésage sont aussi trollifère que les choix d'indentation (voire plus), mais personnellement je préfère le parenthésage à la "Java" (proche du K&R apparement).
Le parenthésage type Allman je trouve que c'est de la perte de place et du coup de lisibilité (on n'embrace pas tout le code d'un seul coup d'oeil) :
vsCode:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17 int main(int argc, char *argv[]) { ... while (x == y) { something(); somethingelse(); if (some_error) { /* the curly braces around this code block could be omitted */ do_correct(); } else { continue_as_usual(); } } finalthing(); ... }
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22 int main(int argc, char *argv[]) { ... while (x == y) { something(); somethingelse(); if (some_error) { /* the curly braces around this code block could be omitted */ do_correct(); } else { continue_as_usual(); } } finalthing(); ... }
C'est en effet trollifère car pour ma part j'ai l'opinion exactement inverse sur la lisibilité :mrgreen:
Si le fait de embracer (c'est de l'anglais, mais il semble que le verbe existait en vieux français) le code d'un seul coup d'oeil (ou si on était payé à l'économie de lignes) était un argument recevable, les déclarations de variables devraient avoir cette forme :
Code:int aVariable; string anotherVariable; double etcVariable;
Moi qui ai beaucoup de mal à lire les blocs condensés, que j'appelle en général des "pâtés" ;), je préfère donc de loin le code aéré et peu importe si celui-ci provoque ce que certains voient comme de la perte de place.
En fait, pour ce qui est de permettre d'avoir une vision globale et rapide de l'action d'une méthode ou fonction, tout dépend de ce qu'elle contient et de la manière dont c'est formalisé. Le code condensé avait bien plus de légitimité lorsque les écrans avaient encore des dimensions très restreintes. Quoi qu'il en soit et en ce qui me concerne, je pense qu'effectivement ce genre de débat est plutôt vain, tout simplement parce que tout le monde n'a pas la même façon de percevoir et analyser un code.
Donc, toujours selon moi, mettre une accolade en fin de ligne à côté plutôt absurde mais avec le temps je m'en suis accommodé. Pour pallier cela, j'ajoute systématiquement une ligne vide après l'accolade ouvrante. C'est donc un format hybride que je pratique et le fait que l'accolade soit à la fin des lignes ne m'embête pas, signe que ce n'est pas tant l'accolade le problème mais bien les textes trop condensés.
Ensuite, je suis tout à fait d'accord avec le fait que si une méthode est trop longue, cela pose des problèmes pour analyser rapidement l'algorithme de celle-ci. C'est pourquoi, au lieu d'incriminer les accolades ouvrantes en début de ligne ou les lignes vides, il faut attacher davantage d'importance à la formalisation de celle-ci. Cela veut dire, faire en sorte que tout ce qui est un tant soit peu compliqué à lire ou tout ce qui prend beaucoup de lignes (ex : remplissage d'un bean avec plein d'attributs par exemple), soit relégué dans des méthodes explicites de par leur nom.
Voilà, donc normalement en définissant des règles qui imposent un nombre de lignes relativement restreint par méthode/fonction, on peut se permettre d'avoir un code aéré, qui selon moi demeure beaucoup plus lisible.
Bref, on n'arrivera jamais à satisfaire tout le monde, donc on aura sans doute fait un progrès, lorsque les éditeurs de code permettront de présenter efficacement le code selon les goûts du développeur, sans impact sur les fichiers physiques et qu'il soit ensuite très facile de basculer d'un type de présentation à un autre.
Un autre progrès me semblerait intéressant, ce serait de guider en permanence la saisie du code, de manière à ce que le développeur n'ait pas à s'en préoccuper (ça se fait dans certains éditeurs depuis un bail me semble-t-il). Egalement, ces éditeurs pourraient se rapprocher de ce qu'est un éditeur de texte tel que Word/OO, c'est-à-dire en permettant de la mise en forme plus poussée. Par exemple, en ayant des marges verticales à intervalle adaptatif selon le contexte, comme faire une séparation plus prononcée entre la signature d'une méthode et le contenu de celle-ci (personnellement, je ne mettrais plus de ligne vide).
Tout ceci a un coût c'est sûr mais je verrais cela comme une bonne chose pour couper court à ce genre de débat, source de frustrations et pertes de temps :)
Pour ce qui est du troll éternel Allman vs K&R, je dirait qu'il n'a vraiment pas lieu d'être. Non seulement la différence n'est au final pas vraiment importante, mais en plus ils peuvent se mélanger sans que ça pose vraiment de problème de lisibilité tant que l'indentation reste propre.
Personnellement j’utilise le K&R, qui a l'avantage d'être plus concis, sauf dans des cas particuliers ou le Allman apporte vraiment un plus de lisibilité comme
où il est utile pour bien séparer la condition du corps du bloc.Code:
1
2
3
4
5
6 if( condition longue && complexe && sur plusieurs lignes) { code }
Le problème des getter/setter n'a rien a voir avec l'introspection, ou la lisibilité, c'est même plutôt une plaie à ce niveau.Citation:
Envoyé par Glob
Ils sont là car ils servent d'interface aux javabean. Un bean se doit d'offrir une encapsulation forte. Grâce au getter/setter les beans ont un contrôle complet sur leur propriétés qu'il peuvent restreindre (read/write only), vérifier, générer à la voler, ... etc
Certes c'est lourd de faire un getter/setter quand on ne fait qu'une opération d'écriture/lecture de variable (Sun/Oracle devrait vraiment se pencher sur une syntaxe spéciale pour les propriétés). Mais ça permet de pouvoir faire évoluer l'opération dans le futur pour par exemple ajouter un contrôle sur un setter, ce qui n'est pas possible avec un accès direct à un champ.