URL: https://linuxfr.org/news/outils-utiles-pour-developpeur Title: Outils utiles pour développeur Authors: Eiffel Davy Defaud, Lucas, palm123, kp, Benoît Sibaud, BAud, Tonton Th, Jehan, Nÿco, RyDroid, Pierre Jarillon, Nils Ratusznik, Jiehong, ZeroHeure, ɹǝıʌıʃO et Storm Date: 2016年02月23日T17:05:19+01:00 License: CC By-SA Tags: développement, sco, fortran, debian, développeur, compilateur et gdb Score: 59 Le but de cette dépêche est de recenser quelques outils utiles pour les développeurs (pas uniquement C et C++) et de donner accès à des ressources intéressantes pour leur prise en main. Tout d’abord comment définit‐on un « outil utile » ? Ce sont des logiciels (libres, c’est mieux) qu’il n’est pas obligatoire d’utiliser mais qui permettent de gagner en productivité (ou de moins se prendre la tête avec un bogue). Ces outils sont utilisables indépendamment, mais utilisés ensemble peuvent former un tout qui donne les fonctionnalités d’un [environnement de développement intégré](https://fr.wikipedia.org/wiki/Environnement_de_d%C3%A9veloppement). Il est fort probable que pour certains cette dépêche vienne enfoncer des portes ouvertes. Mais pensez aux nouveaux pour qui elle sera, peut‐être, profitable. ---- ---- # Makefile _Voir aussi CMake plus loin._ [Make](https://fr.wikipedia.org/wiki/Make) est sûrement l’outil le plus connu et donc le plus utilisé, mais savez‐vous vraiment tirer parti de toute sa puissance ? Make est un utilitaire qui permet d’automatiser la compilation. Pour fonctionner, il a besoin d’un fichier `Makefile` qui contiendra essentiellement des blocs ayant cette apparence : ```make cible : dépendances commandes à exécuter ``` Il est possible de déclarer des variables, pour faciliter l’écriture et la maintenance de fichiers `Makefile`. Certaines implémentations de Make proposent aussi des extensions, comme des variables internes qui accélèrent l’écriture de tels fichiers, comme : * `$@`, le nom de la cible ; * `$<`, le nom de la première dépendance ; * `$^`, la liste des dépendances. Comme cette dépêche n’a pour but que la présentation des outils, voici un bon tutoriel d’[introduction à Makefile](http://gl.developpez.com/tutoriel/outil/makefile/) pour débuter. # CTags [CTags](https://en.wikipedia.org/wiki/Ctags) est un outil très utile quand votre projet commence à avoir pas mal de fichiers. En effet, il permet de retrouver la déclaration ou la définition d’une variable ou d’une fonction. Il existe de nombreux greffons pour les éditeurs les plus connus (emacs, vim, kate...). # Valgrind [Valgrind](https://fr.wikipedia.org/wiki/Valgrind) est en fait un ensemble d’outils. Celui qui nous intéresse dans le cadre de cette dépêche est **MemCheck**. Il permet d’exécuter un programme et d’obtenir une synthèse de l’état de son tas. Ainsi, il est facile de détecter et corriger les fuites mémoire avec un tel outil. Je vous recommande cette [introduction à _memcheck_](https://openclassrooms.com/courses/debuguer-facilement-avec-valgrind). # Time [Time](https://fr.wikipedia.org/wiki/Time_%28Unix%29) est une simple commande Unix qui permet de mesurer la durée d’exécution d’un programme. De prime abord, ça ne paye pas de mine, mais cela peut se révéler assez utile. # Doxygen [Doxygen](https://fr.wikipedia.org/wiki/Doxygen) permet de générer de la documentation dans plusieurs formats (comme HTML ou $\LaTeX$) pour plusieurs langages de programmation (C, C++, Java, VHDL...). Pour ce faire, il faudra ajouter des commentaires avec une syntaxe un peu particulière à certains endroits de votre code, par exemple, pour documenter une fonction vous devrez ajouter le commentaire avant son prototype. Voici le lien d’une [initiation à Doxygen](http://franckh.developpez.com/tutoriels/outils/doxygen/). # Clang/LLVM [Clang](http://fr.wikipedia.org/wiki/Clang) est un compilateur C, C++ et Objective-C qui s’appuie sur [LLVM](https://fr.wikipedia.org/wiki/LLVM "Low Level Virtual Machine — machine virtuelle de bas niveau"). Il tente d’être compatible avec GCC (il utilise les mêmes options) et avec [MSVC](https://fr.wikipedia.org/wiki/Visual_C%2B%2B "Microsoft Visual C++"). Il utilise une licence libre non [[copyleft]]. Il s’approche peu à peu de GCC au niveau performance du code généré, mais il a surtout une interface utilisateur bien meilleure (même s’il a poussé GCC à de gros efforts à ce niveau) : * il affiche erreurs et diagnostic en couleurs de façon très claire ; * il propose des corrections pour certaines erreurs (fautes de frappe) ; * il est plus rapide pour compiler que GCC. Autre gros point fort, sa conception est modulaire et il expose une énorme partie de ses fonctionnalités dans des bibliothèques (par exemple, il est très simple de parcourir l’[AST](https://fr.wikipedia.org/wiki/Arbre_syntaxique_abstrait "Arbre syntaxique abstrait")), ce qui permet à beaucoup d’outils d’exister autour de lui : * [_clang-format_](http://clang.llvm.org/docs/ClangFormat.html) pour l’indentation du code, non pas ligne à ligne, mais globalement. Il peut, par exemple, transformer un appel de fonction avec des paramètres sur des lignes isolées en un appel mono‐ligne si le résultat n’est pas trop long. Debian fournit un [paquet](https://packages.debian.org/stretch/clang-format) ; * [_clang-tidy_](http://clang.llvm.org/extra/clang-tidy/) propose des détections et corrections de bogues courants. C’est une collection de vérifications (*checks*) et il est assez aisé d’en ajouter de nouvelles. Debian propose un [paquet](https://packages.debian.org/stretch/clang-tidy) ; * [_clang static analyzer_](http://clang-analyzer.llvm.org/) est, comme son nom l’indique, un analyseur statique (comme _cppcheck_). Il tente de trouver des bogues en lisant le code. Il est assez utile malgré des faux positifs assez présents ; * _clang_ et LLVM ont introduit des [_sanitizers_](https://github.com/google/sanitizers) qui permettent d’instrumenter le code pour trouver des bogues à l’exécution (comme Valgrind). Les plus connus sont ASAN et TSAN (*address sanitizer* et *thread sanitizer*), mais d’autres se sont greffés au cours du temps. Ils ont été portés sous GCC. Ils sont vraiment très puissants et pratiques pour détecter des bogues lors des tests. En particulier, sous GCC [_undefined behaviour sanitizer_](https://developerblog.redhat.com/2014/10/16/gcc-undefined-behavior-sanitizer-ubsan/). # GDB (GNU Debugger) # [GDB](https://fr.wikipedia.org/wiki/GNU_Debugger) est le débogueur standard du projet GNU. Il est portable sur de nombreux systèmes type Unix et fonctionne pour plusieurs langages de programmation, comme le C, le C++ et le Fortran. Il est aussi possible d’utiliser [_rr_](http://rr-project.org/) pour rejouer ce qui a été mémorisé. # CMake [CMake](https://fr.wikipedia.org/wiki/CMake) est un moteur de production (_build automaton_) de plus haut niveau que Make ou SCons. Il est à placer au même niveau qu'Autotools puisqu'il permet de générer des Makefiles. Il utilise un DSL ([_Domain Specific Language_](https://fr.wikipedia.org/wiki/Langage_d%C3%A9di%C3%A9) ou langage dédié) pour ses fichiers de configuration pour décrire les constructions (_builds_) et génère des fichiers `Makefile` ou équivalent pour _make_, [_ninja_](https://ninja-build.org/), voire carrément pour des [EDI](https://fr.wikipedia.org/wiki/Environnement_de_d%C3%A9veloppement "Environnement de développement intégré"), tels que Visual Studio, XCode et d’autres. Un exemple vaut mieux qu’un long discours : ```cmake cmake_minimum_required (VERSION 2.8.11) project (HELLO) add_executable (helloDemo demo.cxx demo_b.cxx) target_include_directories (Hello includes) ``` Va compiler un exécutable `helloDemo` à partir des fichiers `demo.cxx` et `demo_b.cxx`, en cherchant les fichiers d’en‐têtes déclarés par les `#include` dans le répertoire `includes`. Quant à l’utilisation : ```sh $ # create build tree $ cmake /path/to/project $ # build $ make ``` ou avec ninja : ```sh $ # create build tree $ cmake -GNinja /path/to/project $ # build $ ninja ``` # Cscope [Cscope](http://cscope.sourceforge.net/) est un navigateur de code source C, créé à l’époque du [[PDP-11]] par les [Bell Labs](https://fr.wikipedia.org/wiki/Laboratoires_Bell "Laboratoires Bell"). Il a été libéré en 2000 par SCO sous une licence BSD. Il utilise une interface texte en mode plein écran.

AltStyle によって変換されたページ (->オリジナル) /