Bonnes pratiques pour rédiger le code MATLAB? [fermé]

Lire Code complet , il fera des merveilles pour tout. Il vous montrera où, comment et quand les choses ont de l'importance. C'est à peu près la Bible du développement logiciel (IMHO.)

MATLAB Programmation lignes Directrices de Style par Richard Johnson est une bonne ressource.

Eh bien, si vous le voulez en termes simples:

je vous conseille les gens à écrire le le plus court lisible programme qui fonctionne .

il y a beaucoup plus de règles sur la façon de formater le code, les variables de nom, Les classes de conception, les responsabilités séparées. Mais vous ne devez pas oublier que toutes ces règles sont seulement là pour s'assurer que votre code est facile à vérifier pour les erreurs, et pour s'assurer qu'il est maintenable par quelqu'un d'autre que le auteur original. Si vous gardez à l'esprit la recommandation ci-dessus, votre programme ne sera que cela.

Cette liste pourrait continuer longtemps, mais certaines choses importantes sont:

• tiret.
• Descriptif des noms de variables.
• Descriptif de la classe / les noms de fonction.
• ne dupliquez pas le code. Si elle a besoin de duplication mettre dans une classe / fonction.
• utiliser des gettors / settors.
• n'exposez que ce qui est nécessaire dans vos objets.
• simple la dépendance de principe.
• Apprendre à écrire de bons commentaires, pas beaucoup de commentaires.
• soyez fiers de votre code!

deux bons endroits pour commencer:

Clean-Code Handbook

Code-Compléter

si vous voulez utiliser quelque chose comme référence ou étiquette, je suis souvent les conventions officielles de style Google pour quelque langue que je travaille, comme pour C++ ou pour Python .

La Pratique de la Programmation par Rob Pike et Brian W. Kernighan a aussi une section sur le style que j'ai trouvé utile.

tout d'abord," codes " n'est pas le mot juste à utiliser. Un code est une représentation d'autre chose, généralement numérique. Les mots corrects sont "code source", et le pluriel du code source est code source.

--

la Rédaction d'un bon de code source:

1. Commenter votre code.
2. utilisez des noms de variables plus longs que plusieurs lettres. Entre 5 et 20 est une bonne règle de base.
3. Des lignes de code plus courtes ne sont pas meilleures - utilisez des espaces blancs.
4. être "intelligent" avec votre code est une bonne façon de vous confondre vous-même ou une autre personne plus tard.
5. décompose le problème en ses composantes et utilise la conception hiérarchique pour assembler la solution.
6. rappelez-vous que vous devrez changer votre programme plus tard.
7. commentez votre code.

Il ya beaucoup de modes la programmation informatique. Leurs promoteurs considèrent ceux qui ne suivent pas la lubie d'aveuglement, et pas très. À l'heure actuelle, les principales DCP semblent être "développement basé sur les essais" et "Agile". La mode dans les années 1990 était la "programmation orientée objet". Apprenez les parties centrales utiles des idées qui se présentent, mais ne soyez pas dogmatiques et rappelez-vous que le meilleur programme est celui qui fait le travail qu'il doit faire.

très exemple insignifiant de code trop condensé sur le dessus de ma tête

for(int i=0,j=i; i<10 && j!=100;i++){
     if i==j return i*j; 
     else j*=2;
}}

alors que c'est plus lisible:

int j = 0;
for(int i = 0; i < 10; i++)
{
   if i == j 
   {
      return i * j;
   }
   else
   { 
     j *= 2;
     if(j == 100)
     {
        break;
     }
   }
}

dans le deuxième exemple, la logique de sortie de la boucle est clairement visible; dans le premier exemple, la logique est enchevêtrée dans le flux de commande. Notez que ces deux programmes font exactement la même chose. mon style de programmation prend beaucoup de lignes de code, mais je n'ai jamais rencontré une seule plainte à ce sujet étant difficile comprendre de manière stylistique, alors que je trouve les approches plus condensées frustrant.

un programmeur expérimenté peut lire et lira les deux - ce qui précède peut les faire s'arrêter un moment et considérer ce qui se passe. En forçant le lecteur à s'asseoir et regarder le code n'est pas une bonne idée. Le Code doit être évident. Chaque problème a une complexité intrinsèque à exprimer sa solution. Code ne doit pas être plus complexe que la complexité de la solution, si à tous possible .

voilà l'essence de ce que l'autre affiche tentait de véhiculer - ne faites pas durer le programme plus longtemps que nécessaire. Longer a deux significations: plus de lignes de code (c.-à-d., mettre des accolades sur leur propre ligne), et plus complexe. Rendre un programme plus complexe que nécessaire n'est pas une bonne chose. Le rendre plus lisible est une bonne chose.

Avoir un coup d'oeil à 97 Choses Que Tout Programmeur Devrait Savoir .

C'est gratuit et contient beaucoup de perles comme celle-ci:

il y a une citation que je pense être particulièrement bon pour tous les logiciels les développeurs à connaître et se tenir proche de leurs cœurs:

beauté du style et de l'harmonie et de la grâce et bon rythme dépend de la simplicité. - Plato

En une phrase, je pense que cela résume les valeurs que nous, en tant que logiciel les développeurs devraient aspirer.

il y a un certain nombre de choses que nous nous efforçons pour dans notre code:

• lisibilité
• maintenabilité
• vitesse de développement
• la qualité insaisissable de la beauté

Platon dit nous le permettre facteur pour toutes ces qualités est simplicité.

le Guide de style Python est toujours un bon point de départ!

les normes européennes pour L'écriture et la documentation du Code Fortran 90 échangeable ont été dans mes favoris, comme pour toujours. Aussi, il y avait un fil ici, puisque vous êtes intéressé par MATLAB, sur l'organisation MATLAB code .

personnellement, j'ai trouvé que j'ai appris plus sur le style de programmation en travaillant à travers SICP qui est L'Intro de MIT pour Comp SCI text (je suis environ un quart du chemin à travers.) Que n'importe quel autre livre. Ceci étant dit, Si vous allez travailler en Python, Le Guide de style Google est un excellent endroit pour commencer.

j'ai lu quelque part que la plupart des programmes (scripts de toute façon) ne devraient jamais être plus que quelques lignes de long. Toutes les fonctionnalités nécessaires devraient être résumé en fonctions ou en classes. Je suis plutôt d'accord.

de nombreux points positifs ont été soulevés ci-dessus. J'ai vraiment de la deuxième tous les ci-dessus. Je voudrais également ajouter que l'orthographe et la cohérence dans le codage être quelque chose que vous pratiquez (et aussi dans la vie réelle).

j'ai travaillé avec des équipes offshore et bien que leur anglais soit assez bon, leurs fautes d'orthographe ont causé beaucoup de confusion. Ainsi, par exemple, si vous avez besoin de chercher une fonction (par exemple, getFeedsFromDatabase) et qu'ils écrivent base de données erroné ou quelque chose d'autre, cela peut être un gros ou petit mal de tête, selon le nombre de dépendances que vous avez sur cette fonction particulière. Le fait qu'il se répète encore et encore dans le code tout d'abord, vous conduire noix, et le deuxième, il est difficile à analyser.

Également, suivre la cohérence en termes de nommage des variables et des fonctions. Il y a de nombreux protocoles à suivre, mais tant que vous êtes cohérent dans ce que vous faites, d'autres avec qui vous travaillez seront en mesure de mieux lire votre code et être heureux pour elle.

à peu près tout ce qui est dit ici, et quelque chose de plus. À mon avis, Le Meilleur site concernant ce que vous recherchez (en particulier le zen de pièces python sont amusant et vrai)

http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html

parle de PEP-20 et PEP-8, quelques œufs de Pâques (fun stuff), etc...

vous pouvez jeter un oeil au cours en ligne de Stanford: méthodologie de programmation CS106A . L'instructeur a donné plusieurs très bonnes instructions pour écrire le code source.

Certains d'entre eux sont comme suit:

1. écrire des programmes pour les gens à lire, pas seulement pour les ordinateurs à lire. Les deux doivent être capables de le lire, mais il est beaucoup plus important qu'une personne le lise et le comprenne, et que l'ordinateur exécute correctement. Mais c'est le premier grand génie logiciel principe de penser.

2. comment faire des commentaires:  mettre en commentaires pour clarifier les choses dans le programme, qui ne sont pas évidentes

3. comment faire la décomposition

   1. une méthode résout un problème
   2. chaque méthode a un code approximatif 1~15lignes
   3. Donner des méthodes de bons noms de
   4. Écrire un commentaire pour le code

Essais Unitaires

Python et matlab sont des langages dynamiques. Au fur et à mesure que votre base de code s'agrandira, vous serez forcé de reformuler votre code. Contrairement aux langages statiquement typés, le compilateur ne détectera pas les parties 'cassées' dans votre projet. L'utilisation de cadres de test à l'unité comme xUnit non seulement compensent les contrôles de compilateur manquants, ils permettent le remaniement avec vérification continue pour toutes les parties de votre projet.

Source Contrôle

Suivez votre code source avec un système de contrôle de version comme svn , git ou tout autre dérivé. Vous pourrez faire des allers-retours dans votre historique de code, créer des branches ou créer des tags pour les versions déployées/publiées.

Suivi Des Bogues

Utilisez un système de suivi des bogues, si possible connecté à votre système de contrôle des sources, afin de rester au courant de vos problèmes. Vous pourriez ne pas être en mesure, ou forcé, de régler les problèmes tout de suite.

Réduire L'Entropie

En intégrant de nouvelles fonctionnalités dans votre base de code existante, vous ajouterez plus de lignes de code, et potentiellement plus de complexité. Cela augmentera l'entropie. Essayez de garder votre conception propre, en introduisant une interface, ou une hiérarchie d'héritage afin de réduire l'entropie à nouveau. Ne pas payer attention à l'entropie de code rendra votre code Impossible à maintenir au fil du temps.

Tout ce qui précède

Le codage pur des sujets connexes, comme l'utilisation d'un guide de style, pas la duplication de code,..., il a déjà été mentionné.

un petit ajout aux réponses merveilleuses déjà ici concernant Matlab :

• évitez les longs scripts, écrivez plutôt des fonctions (sous-routines) dans des fichiers séparés. Cela rendra le code plus lisible et plus facile à optimiser.

• utilisez les fonctionnalités intégrées de Matlab. C'est-à-dire, en savoir plus sur les nombreuses fonctions que Matlab offre au lieu de réinventer la roue.

• utiliser section de code , et quelle que soit l'autre structure de code que la dernière version de Matlab offre.

• apprendre à faire des comparaisons votre code en utilisant timeit et profile . Vous découvrirez que parfois pour les boucles sont la meilleure solution.

le meilleur conseil que j'ai reçu lorsque j'ai posé cette question était le suivant:

Never code while drunk.

Rendre lisible, le rendre intuitif, le rendre compréhensible, et de faire des commentaires.