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

Les rubriques (actu, forums, tutos) de Développez
Réseaux sociaux


 Discussion forum

Sur le même sujet
Le , par Hinault Romaric, Responsable Actualités
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


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de deuz59 deuz59
http://www.developpez.com
Membre habitué
le 05/06/2011 20:51
Citation Envoyé par _skip  Voir le message
C'est ça la phrase clé : dans la mesure du possible. Il arrive tout de même souvent qu'on soit amené à faire des choses qui semblent un peu contre-intuitives ou superflues mais qui ont une certaine importance, style une optimisation ou un test supplémentaire qui évite une défaillance dans une librairie tierce.

Pour le reste, je maintiens que les commentaires ne sont pas une documentation en soi. Il existe de supers outils gratuits pour faire de la doc, des diagrammes, et tout ça, et des solutions style wiki très faciles à mettre en oeuvre pour les publier (voir mes posts précédents).

Le commentaire demeure un outil qu'il faut utiliser à bon escient, en fait si on insiste ici sur son inutilité c'est que dans 90% des cas où on dit "il faut commenter" c'est pour une mauvaise raison et c'est un contre emploi qui provoque l'effet inverse de ce qu'on veut faire, à savoir un code propre et maintenable..malheureusement tant qu'on ne sera pas suffisamment catégorique sur les méfaits des commentaires, les règles du style 'tout commenter' demeureront dans les subconscients et on continuera à commenter en pensant qu'il était impossible de faire autrement alors que c'est quasiment toujours possible. La bonne conduite à tenir est donc de coder en faisant tout pour ne pas commenter et laisser un commentaire la mort dans l'âme en ayant bien étudié la raison de ce commentaire et fait son maximum pour l'éviter.....il restera toujours des commentaires mal placés ou complètement inutiles, c'est pour ça que le refactoring est une autre bonne règle à adopter (prérecquis : Tests Unitaires pour limiter les risques de régression) => si tu vois qu'un collègue à laisser un commentaire en pensant qu'il ne pouvait pas faire autrement alors que c'est clairement parcequ'il n'a pas été au bout pour faire du bon code, revoit son code et supprime le commentaire inutile.....
Avatar de deuz59 deuz59
http://www.developpez.com
Membre habitué
le 05/06/2011 20:54
Citation Envoyé par el_slapper  Voir le message
Bon, on ne sera jamais d'accord sur ce sous-débat.....

Pour faire bref(enfin essayer), je dirais que nous ne vivons pas dans un monde parfait, et que la doc SERA perdue. Nous ne vivons pas dans un monde parfait et il y aura du code non-parfait. Nous ne vivons pas dans un monde parfait, et notre surccesseur ne sera pas meilleur que nous. Et il sera heureux de trouver un peu de vrai Français qui lui dise deux-trois trucs utiles.

Mais bon, c'est un vieux débat, qui plus est à la marge, car je suis d'accord avec ton prémisse Juste, je crois que même si le code n'a pas besoin de commentaires pour être compris, un commentaire sera quand même utile. Toi, tu ne le considères pas comme utile. Et on est d'accord sur notre désaccord.

On est bien d'accord mais c'est surtout pour cela qu'il faut faire en sorte de "rendre le monde meilleur" et ne pas continuer de suivre de mauvaises règles par dépit => faisons en sorte d'améliorer les choses et non de les prendre comme une fatalité
Avatar de Bluedeep Bluedeep
http://www.developpez.com
Inactif
le 08/06/2011 17:51
Citation Envoyé par el_slapper  Voir le message
@Bourgui : Essayes de maintenir du code qui a 36 ans d'âge

Puis

2 lignes avant un bloc ... plus de 1M€ sur le TIP

En tout cas, il avait prévu l'euro en 1972, ça réclame une belle capacité d'anticipation
Avatar de rmaker rmaker
http://www.developpez.com
Membre Expert
le 09/06/2011 10:50
Tester, tester, tester, règle numéro 0.
Avatar de Ozeil Ozeil
http://www.developpez.com
Membre habitué
le 09/06/2011 11:01
La première règle pour un débutant c'est d'avoir des bugs pour ensuite apprendre à les résoudre ou apprendre à chercher des réponses pour les résoudre.
Avatar de shenron666 shenron666
http://www.developpez.com
Expert Confirmé Sénior
le 09/06/2011 11:14
Citation Envoyé par rmaker  Voir le message
Tester, tester, tester, règle numéro 0.

tu ne peux pas mettre cette règle en premier, il faut d'abord coder avant de tester
Avatar de deuz59 deuz59
http://www.developpez.com
Membre habitué
le 09/06/2011 16:39
Citation Envoyé par shenron666  Voir le message
tu ne peux pas mettre cette règle en premier, il faut d'abord coder avant de tester

ok donc coder le test puis tester tester tester
Avatar de DrHelmut DrHelmut
http://www.developpez.com
Membre actif
le 05/07/2011 17:25
Citation Envoyé par shenron666  Voir le message
tu ne peux pas mettre cette règle en premier, il faut d'abord coder avant de tester

oui et non, avec le TDD
Avatar de hegros hegros
http://www.developpez.com
Membre expert
le 08/07/2011 15:46
Citation Envoyé par DrHelmut  Voir le message
oui et non, avec le TDD

Et l'ATDD
Avatar de kisitomomotene kisitomomotene
http://www.developpez.com
Membre confirmé
le 08/07/2011 16:01
Citation Envoyé par DrHelmut  Voir le message
oui et non, avec le TDD

Je ne crois pas que le TDD demande de tester avant de coder, je crois plutôt que le TDD demande d'écrire le code de test avant d'ecrire le code à tester.
Mais on ne peut tester (comprendre executer le code de test) avant d'avoir écrire le code principale
Avatar de hegros hegros
http://www.developpez.com
Membre expert
le 08/07/2011 16:11
Citation Envoyé par kisitomomotene  Voir le message
Mais on ne peut tester (comprendre executer le code de test) avant d'avoir écrire le code principale

Tester ce n'est pas simplement 'exécuter du code' c'est aussi, avec l'ATDD d'autant plus, spécifier notamment les détails fonctionnels et techniques.

Donc oui on écrit un test au sens ATDD ou TDD (qui là pour le coup est aussi du code) avant d'écrire une ligne de code de production

La qualification/ou test d'acceptation effectivement ne peut être réalisé avant d'avoir écrit tout le code d'une fonction
Offres d'emploi IT
(H/F) Country Manager Hollande (Ecommerce)
CDI
EMPLOI DIGITAL - Rhône Alpes - Lyon (69000)
Parue le 27/10/2014
Maitrise d'ouvrage (mo) h/f
Stage
Société Générale France - Ile de France - Paris (75000)
Parue le 10/10/2014
Qa manager (h/f)
CDI
CAREER BOOSTER - Ile de France - IGNY (70700)
Parue le 07/10/2014

Voir plus d'offres Voir la carte des offres IT
 
 
 
 
Partenaires

PlanetHoster
Ikoula