IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Quelles règles les programmeurs débutants devraient-ils toujours respecter ?
Un développeur expérimenté livre ses 7 règles d'or

Le , par Hinault Romaric

407PARTAGES

13  1 
A ses débuts, le programmeur inexpérimenté a tendance à fixer son attention sur la fonctionnalité à produire, quelque soit la quantité de ligne de code, les procédures et les fonctions utilisées pour produire le résultat final. Et ceci sans comprendre (parfois) ce qu'il fait vraiment ou les spécificités du langage.

Paul Vick, un développeur reconnu et spécialisé dans les bases de données et les langages, a travaillé sur plusieurs produits Microsoft dont SQL Server, Visual Basic ou le runtime .NET. Dans un billet de blog, il s'est inspiré des « sept règles pour les écrivains débutants » pour en proposer une version aux jeunes développeurs et leur éviter de faire trop d'erreurs.

Les voici.

Règle numéro 1, le programmeur débutant ne doit pas écrire de longues procédures. Une procédure ne devrait pas avoir plus de dix ou douze lignes de code.

Deux, chaque procédure doit avoir un objectif clair. Un bon programme doit avoir des procédures claires, sans cumul.

Trois, les programmeurs débutants ne doivent pas utiliser les fonctions fantaisistes du langage. Pour Paul Vick, il est mal pour un débutant d'utiliser autre chose que des déclarations de variables, les appels de procédures, des opérateurs (arithmétiques, comparaisons, etc.) et les fonctions de contrôle de flux. Selon lui, l'utilisation des fonctions simples oblige à réfléchir à ce que l'on écrit.

Règle numéro quatre, ne jamais utiliser les fonctionnalités du langage dont vous n'êtes pas sûr(e) du résultat ou du rôle. Une règle d'or indépassable pour Paul Vick, qui estime que si elle n'est pas respectée par un débutant, il devrait purement et simplement changer de métier.

Règle numéro cinq, les débutants doivent à tout prix éviter le copier/coller. Sauf, évidemment, s'ils veulent copier le code d'un programme qu'ils ont écrit.

Six, le débutant doit éviter l'abstrait, et toujours opter pour le concret.

Et enfin la règle numéro sept : applique les six règles ci-dessus chaque jour pendant au moins six mois.

La pratique de la programmation en suivant ces 7 règles d'or peut s'avérer très gênant reconnaît Paul Vick. Mais pour lui, c'est un excellent moyen d'apprendre un langage de programmation.

Et pourrait même permettre, conclut-il avec humour, de se débarrasser des mauvaises habitudes acquises à l'Université.

Et vous ?

Quelles sont vos « 7 Règles d'Or » de la programmation ?

Et que pensez-vous de ces règles de Paul Vick?

Source : Blog Paul Vick

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de RomainVALERI
Expert confirmé https://www.developpez.com
Le 19/05/2011 à 17:46
Citation Envoyé par Hinault Romaric Voir le message
Six, le débutant doit éviter l'abstrait, et toujours opter pour le concret.
Je crois que même si ça avait un sens, je ne serais pas d'accord.

Non, mais franchement quoi...
Attends moi aussi j'en ai des comme ça...

Un vrai programmeur doit programmer "lumineux" et pas "ténébreux".
Un vrai programmeur doit programmer "odorant" et pas "nauséabond".

Au bout d'un moment, ce genre de métaphore hyper large, c'est un peu trop.... abstrait, non ?
18  0 
Avatar de
https://www.developpez.com
Le 19/05/2011 à 16:39
ça peut paraitre un troll mais a mon avis els commentaire, dans 90 % des cas gache le code.

Les langage sont pourvu d'une fonctionnalité qui permet d'éviter les commentaires : les noms de fonctions et de variable a taille illimité (ou presque) et les accolades !

les commentaires j'en mets : pour les API (avec la notation pour que ça apparaisse dans l'ide), et pour les bout de code vraiment bizarre qui applique des business rules de l'espace.

mais le coup de

"
//DEBUT ma procedure qui fait ça
....
//FIn ma procedure qui fait ça
"

Le conseil de " Use as few files as possible." est le pire de tous, rien de plus horrible qu'un fichier de code de 10 000 lignes avec 50 classes, la dedans je pars avec resharper et je t'en fait 50 réparti en namespace, comme ça rien qu'en voyant les noms des fichiers tu comprend comment le mec a conçu son appli.
16  1 
Avatar de Bebel
Membre éprouvé https://www.developpez.com
Le 19/05/2011 à 15:42
La règle 1 est très limitative. 15 lignes c'est vraiment peu.

Par contre, je trouve qu'il manque une règle très importante : les commentaires.

L'idéal serait même de commencer à poser l'algo en commentaire avant de commencer à coder.
16  2 
Avatar de Traroth2
Membre émérite https://www.developpez.com
Le 19/05/2011 à 16:52
Citation Envoyé par Bebel Voir le message
La règle 1 est très limitative. 15 lignes c'est vraiment peu.

Par contre, je trouve qu'il manque une règle très importante : les commentaires.

L'idéal serait même de commencer à poser l'algo en commentaire avant de commencer à coder.
Franchement, attention à ne pas sur-commenter le code. Les commentaires peuvent créer plus de problèmes qu'ils n'en résolvent : on maintient le code, mais on ne maintient pas forcément aussi bien les commentaires. Et des commentaires obsolètes, c'est pire que pas de commentaires du tout. Ce que je dis généralement à mes stagiaires concernant les commentaires, c'est : commentez dès que le code n'est plus immédiatement compréhensible, c'est à dire dès que vous faites quelque chose d'astucieux (terme péjoratif, à mes yeux, concernant du code), et mieux encore, essayez d'éviter de faire des choses astucieuses en matière de programmation. L'intelligence, en matière d'ingénierie logicielle, ne doit pas se situer au niveau de la programmation, parce que ça se termine toujours en catastrophe, mais au niveau de l'analyse et de la conception de votre application. Si vous structurez bien votre code, vous ne devriez pas avoir besoin de faire de trucs astucieux pour vous en tirer au final. Autrement dit : keep it simple, stupid!
13  0 
Avatar de clavier12AZQSWX
Membre éclairé https://www.developpez.com
Le 19/05/2011 à 16:18
la régle n°1 pour le débutant : C O M M E N T E R !

régle n°2 : tester et faire tester son travail

régle n°3 : ne pas travailler et facebooker en même temps !
14  2 
Avatar de gwinyam
Membre chevronné https://www.developpez.com
Le 20/05/2011 à 9:19
Citation Envoyé par cs_ntd Voir le message
Déja pour moi, un débutant programmeur n'a rien a faire dans une entreprise, c'est un étudiant en informatique, ou un autodidacte. Donc il n'y a pas vraiment de contraintes de qualité, etc... un programmeur débutant travaille pour lui.
Bravo l'ouverture d'esprit professionnelle. Tout comme le suggère Reward, les contrats d'apprentissage, les stages, ça sert à quoi? Justement à ça, à apprendre.

Faut arrêter l'idée de l'informaticien auto-didacte qui apprend dans sa piaule comme un gros galérien et qui est apte à aller en entreprise ensuite. C'est pas professionnalisant comme comportement.
13  1 
Avatar de Barsy
Expert confirmé https://www.developpez.com
Le 19/05/2011 à 17:18
Règle numéro 3 : Ne surtout pas leur donner à manger après minuit !!

11  2 
Avatar de sevyc64
Modérateur https://www.developpez.com
Le 22/05/2011 à 10:24
Citation Envoyé par Jitou Voir le message
Donc nourrissez vos lignes de code avec du commentaire, je préconise au minimum 50% de commentaires dans un fichier source,
50% soit 1 ligne de commentaire pour un ligne de code, c'est trop.

La règle communément admise c'est de 6 à 10% soit en gros une ligne de commentaire pour 10 à 15 lignes de code.
Ou, pour ce qui préfèreront, de 1 à 3 lignes de commentaire en début de chaque procédure et fonction.

Et c'est largement suffisant, car avec un code correctement découpé et agencé, des nom de variables et méthodes judicieusement choisis et suffisamment explicites, la plupart des commentaires sont superflus
9  0 
Avatar de spidermario
Membre éprouvé https://www.developpez.com
Le 20/05/2011 à 0:01
Citation Envoyé par Barsy Voir le message
Règle numéro 3 : Ne surtout pas leur donner à manger après minuit !!

Je n’ai jamais compris cette règle. À quel moment n’est-on pas après minuit ?
9  1 
Avatar de Reward
Membre confirmé https://www.developpez.com
Le 20/05/2011 à 8:12
Citation Envoyé par cs_ntd Voir le message
Déja pour moi, un débutant programmeur n'a rien a faire dans une entreprise, c'est un étudiant en informatique, ou un autodidacte. Donc il n'y a pas vraiment de contraintes de qualité, etc... un programmeur débutant travaille pour lui.
Pas d'accord avec ça. N'as-tu jamais vu de contrat en alternance dans ton entreprise, des apprentis ? Ils sont étudiants et ont leur place en entreprise, puis il faut bien commencer un jour.

Tu as donc commencé ton travail dans le développement en étant directement expérimenté, sans passer par la case débutant ? Intéressant !

Sinon je vois une règle manquante, ma numéro 1:

- Un papier, un crayon et de la réflexion !
8  0