Pliage de code - Code folding

Exemple de pliage de code sur du code PHP avec Vim

Code pliage ou moins fréquemment holophrasting est une caractéristique de certains éditeurs de texte , les éditeurs de code source , et IDEs qui permet à l'utilisateur de cacher de manière sélective et affichage - « fold » - sections d'un fichier en cours d' édition comme une partie des opérations d'édition de routine. Cela permet à l'utilisateur de gérer de grandes quantités de texte tout en ne visualisant que les sous-sections du texte qui sont spécifiquement pertinentes à un moment donné.

L'identification des replis peut être automatique, le plus souvent basée sur la syntaxe du langage informatique en question, l'indentation, ou manuelle, soit basée sur un marqueur in-band (enregistré dans le code source) ou spécifié hors bande, uniquement dans l'éditeur.

De nombreux éditeurs fournissent des widgets de divulgation pour le pliage du code dans une barre latérale, à côté des numéros de ligne, indiqués par exemple par un triangle qui pointe sur le côté (s'il est réduit) ou vers le bas (s'il est développé), ou par une zone [-]pour le texte réductible (développé), et un [+]zone pour le texte extensible (réduit). Cette fonctionnalité est couramment utilisée par certains programmeurs informatiques pour gérer les fichiers de code source , et est également fréquemment utilisée dans la comparaison de données , pour afficher uniquement le texte modifié.

Le pliage de texte est une fonctionnalité similaire utilisée dans les éditeurs de pliage , les contours et certains traitements de texte , mais est utilisé pour le texte ordinaire et, s'il est automatique, est basé sur la syntaxe des langues humaines, en particulier les paragraphes ou les niveaux de section, plutôt que la syntaxe d'un ordinateur Langue. Une autre variante du pliage de code est le "pliage de données", qui est implémenté dans certains éditeurs hexadécimaux et est utilisé pour structurer un fichier binaire ou masquer des sections de données inaccessibles dans un éditeur RAM. Il existe plusieurs termes alternatifs pour de telles fonctionnalités, notamment « développer et réduire », « masquer le code » et « contourner ». Dans Microsoft Word , la fonctionnalité s'appelle « schéma réductible ».

Histoire

Le premier exemple connu de pliage de code dans un éditeur est en NLS (système informatique) . Le premier éditeur de pliage largement disponible était probablement l'éditeur SPF (Structured Programming Facility) de 1974 pour les mainframes IBM 370 , qui pouvait masquer les lignes en fonction de leur indentation. Il s'affichait sur des terminaux 3270 à mappage de caractères. C'était très utile pour les langages prolixes comme COBOL . Il est devenu l'Interactive System Productivity Facility ( ISPF ).

Utilisation

Le pliage de code a divers modèles d'utilisation , principalement pour organiser le code ou masquer des informations moins utiles afin que l'on puisse se concentrer sur des informations plus importantes. Les modèles communs suivent.

Décrire

Plus fondamentalement, les applications utilisent le pliage de code pour décrire le code source, en réduisant chaque bloc en une seule ligne. Cela peut être uniquement des blocs de niveau supérieur comme des fonctions et des classes, des blocs imbriqués comme des fonctions et des méthodes imbriquées, ou tous les blocs, notamment des blocs de flux de contrôle. Cela permet d'avoir une vue d'ensemble du code, de le naviguer et de le réorganiser facilement, et d'explorer plus en détail si nécessaire, sans être distrait par un autre code. Du point de vue de l'affichage, cela permet de voir rapidement une liste de toutes les fonctions (sans leur corps), tandis que du point de vue de la navigation, cela remplace la pagination étendue au-delà des fonctions longues - ou la recherche de la cible - en passant directement à la fonction suivante.

Cacher le code passe-partout

Certains langages ou bibliothèques nécessitent un code passe-partout étendu . Cela se traduit par un code extrêmement long, ce qui peut masquer l'essentiel. De plus, le code substantif peut être perdu dans le passe-partout.

Par exemple, en Java, un seul champ privé avec un getter et un setter nécessite au moins 3 lignes, si chacun se trouve sur une ligne distincte :

private String name = null;
public String getName() { return name; }
public void setName(String name) { this.name = name; }

Cela s'étend à 10 lignes avec des sauts de ligne de fonction conventionnels et un espacement entre les fonctions (y compris la nouvelle ligne de fin):

private String name = null;

public String getName() {
    return name;
}

public void setName(String name) {
    this.name = name;
}

La documentation avec Javadoc étend cela à 20 lignes :

/**
 * Property <code>name</code>  readable/writable.
 */
private String name = null;

/**
 * Getter for property <code>name</code>
 */
public String getName() {
    return name;
}

/**
 * Setter for property <code>name</code>.
 * @param name
 */
public void setName(String name) {
    this.name = name;
}

S'il y a beaucoup de tels champs, le résultat peut facilement être des centaines de lignes de code avec très peu de contenu "intéressant" - le pliage de code peut réduire cela à une seule ligne par champ, voire à une seule ligne pour tous les champs. De plus, si tous les champs de routine sont pliés, mais que les champs non routiniers (où getter ou setter ne font pas que retourner ou affecter un champ privé) ne sont pas pliés, il devient plus facile de voir le code substantif.

Réduire les métadonnées

Les métadonnées peuvent être longues et sont généralement moins importantes que les données qu'elles décrivent. Le regroupement des métadonnées permet de se concentrer principalement sur les données, et non sur les métadonnées. Par exemple, une longue liste d' attributs en C# peut être réduite manuellement comme suit :

#region Attributes
[Browsable(false)]
[MergableProperty(false)]
[DefaultValue(null)]
[PersistenceMode(PersistenceMode.InnerProperty)]
[TemplateContainer(typeof(MyType))]
[TemplateInstance(TemplateInstance.Single)] 
#endregion
public ITemplate ContentTemplate
{
    get { return _temp; }
    set { _temp = value; }
}

Le code résultant s'affiche sous la forme :

Attributes
public ITemplate ContentTemplate
{
    get { return _temp; }
    set { _temp = value; }
}

Réduire les commentaires

Les commentaires sont une forme de métadonnées lisibles par l'homme, et de longs commentaires peuvent perturber le flux de code. Cela peut être le cas soit pour un long commentaire pour une courte section de code, comme un paragraphe pour expliquer une ligne, soit pour des commentaires pour les générateurs de documentation , comme Javadoc ou XML Documentation . Le pliage de code permet d'avoir de longs commentaires, mais de ne les afficher qu'en cas de besoin. Dans les cas où un long commentaire a une seule ligne de résumé, comme les docstrings Python, le résumé peut toujours être affiché lorsque la section est réduite, permettant une vue résumé/détaillée.

Affichage de la structure ou du code sandwich dans la programmation structurée

La programmation structurée se compose de blocs de code imbriqués, et de longs blocs de code - tels que de longues instructions switch - peuvent masquer la structure globale. Le pliage du code permet de voir la structure globale et de l'étendre à un niveau spécifique. De plus, dans certaines utilisations, en particulier la programmation structurée stricte (sortie de fonction unique), il existe des modèles de code qui sont difficiles à voir lorsque l'on regarde du code étendu. Par exemple, dans la gestion des ressources en programmation structurée, on acquiert généralement une ressource, suivie d'un bloc de code utilisant la ressource, et terminant par la libération de la ressource. L'appariement acquisition/libération est difficile à voir s'il y a un long bloc de code entre les deux, mais facile à voir si le bloc intermédiaire est plié. De même, dans un code conditionnel comme if...then...else, les blocs secondaires peuvent être éloignés de l'instruction de condition.

Code de regroupement

Les groupes de plis peuvent être utilisés pour regrouper le code, soit par regroupement explicite - similaire à des blocs de commentaires séparant un module en sections, ou des membres de classe dans des groupes associés - soit implicitement, par exemple en regroupant automatiquement les membres de classe par niveau d'accès.

Masquer le code hérité

Le code hérité - ou tout code qu'un développeur ne souhaite pas voir ou modifier à un moment donné - peut être replié afin que les programmeurs puissent se concentrer sur le code considéré.

Masquer les tables de données dans la source

Conventions

Afin de prendre en charge le pliage de code, l'éditeur de texte doit fournir un mécanisme permettant d'identifier les « points de pliage » dans un fichier texte. Certains éditeurs de texte fournissent ce mécanisme automatiquement, tandis que d'autres fournissent des valeurs par défaut qui peuvent être remplacées ou augmentées par l'utilisateur.

Il existe divers mécanismes, grossièrement divisés en automatiques et manuels – nécessitent-ils une spécification de la part du programmeur ? Les points de pliage sont généralement déterminés avec un ou plusieurs des mécanismes suivants. Chacun d'eux a ses propres avantages et difficultés, et il appartient essentiellement aux développeurs qui créent le logiciel d'édition de texte de décider lequel implémenter. Les éditeurs de texte qui prennent en charge plusieurs mécanismes de pliage permettent généralement à l'utilisateur de choisir celui qui convient le mieux au fichier en cours d'édition.

Dépendant de la syntaxe

Les points de pliage dépendant de la syntaxe sont ceux qui reposent sur le contenu du fichier en cours d'édition afin de spécifier où les régions de pliage spécifiques doivent commencer et se terminer. Les points de pliage basés sur la syntaxe sont généralement définis autour de tout ou partie des sous-fonctionnalités standard du langage de balisage ou du langage de programmation utilisé. Celles-ci sont souhaitables car elles sont automatiques et conformes à la structure du code, mais peuvent nécessiter un travail important à mettre en œuvre et du temps de calcul lors de l'édition d'un fichier.

Basé sur l'indentation

Les points de pliage basés sur l'indentation sont généralement spécifiés par la position et la séquence des espaces non imprimables, tels que les tabulations et les espaces, dans le texte. Ceci est le plus souvent utilisé comme une forme simple de pliage basé sur la syntaxe, car l'indentation reflète presque toujours le niveau d'imbrication dans les styles d'indentation pour les langages de programmation structurés.

Cette convention est particulièrement adaptée aux syntaxes qui ont une règle de hors-jeu , de sorte que la structure s'accorde largement avec l'indentation. Les exemples incluent Python et les fichiers texte qui nécessitent une indentation en règle générale par eux-mêmes. Cependant, même dans ces cas, la structure ne correspond pas exactement à l'indent, comme dans la continuation de la ligne , et donc le pliage dépendant de la syntaxe est préféré.

Basé sur des jetons

Les points de pliage basés sur des jetons sont spécifiés à l'aide de délimiteurs spéciaux qui n'ont d'autre but dans le texte que d'identifier les limites des points de pliage. Cette convention peut être comparée aux points de pliage basés sur l'indentation, où des caractères imprimables sont utilisés à la place des espaces. Les jetons délimiteurs les plus courants sont {{{de commencer la section pliée et }}}de la terminer.

Un autre jeton notable est #region( directives C# ), respectivement #Region( directives Visual Basic ), utilisé dans Microsoft Visual Studio Code Editor . Celles-ci sont traitées syntaxiquement comme des directives du compilateur , bien qu'elles n'affectent pas la compilation.

En tant que méthode manuelle, le pliage basé sur des jetons permet une discrétion dans le regroupement du code en fonction de critères arbitraires, tels que les « fonctions liées à une tâche donnée », qui ne peuvent être déduits de l'analyse syntaxique.

Le pliage basé sur des jetons nécessite une signalisation dans la bande, les jetons de pliage étant essentiellement des commentaires structurés et, contrairement à d'autres méthodes, ils sont présents dans le code source et visibles par les autres programmeurs. Cela permet de les partager, mais nécessite également leur utilisation (ou leur conservation) par tous les programmeurs travaillant sur un fichier particulier, et peut entraîner des frictions et une charge de maintenance.

Spécifié par l'utilisateur

Le pliage spécifié par l'utilisateur permet à l'utilisateur de plier des sections de texte à l'aide d'une méthode de sélection générique, mais sans modifier le code source (hors bande), en étant spécifié uniquement dans l'éditeur. Par exemple, un programmeur peut sélectionner certaines lignes de texte et spécifier qu'elles doivent être pliées. Le texte plié peut être anonyme ou nommé, et cela peut être conservé au cours des sessions d'édition ou supprimé. Contrairement au pliage basé sur des jetons, cela ne modifie pas le texte source - il n'est donc pas partagé avec d'autres éditeurs du fichier et n'est pas visible dans le code.

Exemples

Le document suivant contient des jetons pliants ( {{{ ... }}}) :

 Heading 1
 {{{
 Body
 }}}

 Heading 2
 {{{
 Body
 }}}

 Heading 3
 {{{
 Body
 }}}

Lorsqu'elle est chargée dans un éditeur de pliage, la structure hiérarchique sera affichée :

 Heading 1
 {{{ ...

 Heading 2
 {{{ ...

 Heading 3
 {{{ ...

Généralement, un clic sur les {{{marques fait apparaître le corps de texte approprié.

Logiciel avec capacité de pliage de code

L'un des premiers éditeurs de pliage était STET , un éditeur écrit pour le système d'exploitation VM/CMS en 1977 par Mike Cowlishaw . STET est un éditeur de texte (pour la documentation, les programmes, etc.) qui replie des fichiers sur la base de blocs de lignes ; tout bloc de lignes peut être plié et remplacé par une ligne de nom (qui à son tour peut faire partie d'un bloc qui lui-même peut ensuite être plié).

Un éditeur de pliage est apparu dans l' IDE d' occam vers 1983, qui s'appelait Inmos Transputer Development System (TDS) ^, . L'éditeur "f" (dans la liste ci-dessous) est probablement l'héritage le plus intact de ce travail.

L' ordinateur Macintosh avait historiquement un certain nombre d' éditeurs de code source qui « pliaient » des portions de code via des « triangles de divulgation ». Le produit UserLand Software Frontier est un environnement de script qui a cette capacité.

Le pliage est fourni par de nombreux éditeurs de texte modernes, et le pliage basé sur la syntaxe ou la sémantique est désormais un composant de nombreux environnements de développement logiciel . Les éditeurs comprennent :

Autres éditeurs

Voir également

• La section Fonctionnalités de programmation de l' article Comparaison des éditeurs de texte pour plus d'éditeurs prenant en charge le pliage
• Accordéon (GUI) , une technique d'interface utilisateur similaire appliquée aux listes hiérarchiques plutôt qu'au texte

Remarques

Les références

Liens externes

• Qu'est-ce qu'un éditeur de pliage ? par l'auteur de l' feéditeur.
• Description de l'éditeur de pliage utilisé dans occam .