Quelles règles les programmeurs débutants devraient-ils toujours respecter ?
Un développeur expérimenté livre ses 7 règles d'or
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
Sur le même sujet
|
Le 19/05/2011, 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 |



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

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.....