Léa-Linux & amis :   LinuxFR   GCU-Squad   Zarb.Org   GNU
Archive de la liste aide - [Aide] problème avec une fonction dans un script bash
Point 3….. c’est moi le coupable… snifff … 😝
Honte à moi, je vais méditer @°+ 

De : Peko
Envoyé le :mercredi 27 janvier 2016 21:11
À : Liste d'entraide du site http://www.lea-linux.org
Objet :Re: [Aide] problème avec une fonction dans un script bash

1.
> Bon, maintenant, j'ai fait ça rapidement pour donner un coup de main,
> si ce n'est pas souhaité, ben... je m'abstiendrais :)

Non Ilie, ne nous quitte pas!!!  ;-)
Ce n'est pas parce que tu es particulièrement manchot quand tu codes
qu'il faut le prendre mal! :-D


2.
> La convention qui me semble en usage ici, c'est que les constantes
> définies en début de script sont en MAJUSCULES, tandis que les
> variables du programme sont elles en minuscules.


Concernant la référence que tu cites, je pense que les auteurs de ce
livre sont influencés par leurs habitude en langage C.

En langage C Kernighan & Ritchie, ou Ken Thompson m'ont influencé moi
aussi. Notamment quand l'un d'entre eux disait : toujours des
variables en minuscule.

Dans ce langage C, concernant les constantes en tête de fichier, ou
souvent dans les Header files ( fichiers.h en C), oui, les constantes
sont en majuscules.

Sauf que le C n'est pas le shell.

Une constante en C n'est pas une variable, c'est une substitution de
texte qui va être traitée par le préprocesseur de texte lors de la
compilation.



3.
Donc cette habitude qui ressemble à celle du C n'est pas appropriée au shell.

Pourquoi?


Parce qu'en C, tu peux appeler une variable ou une constante [PATH],
et lui assigner une valeur et la changer, et cela n'aura aucun effet
sur la variable d'environnement [PATH] du programme C.


En revanche, dans un script shell, cela a un effet direct, puisque
[PATH] est bien la variable d'environnement du script.

Donc le pgmr  qui code ses variables shell en majuscule prend des risques.


Pourquoi?

1. Parce ton clavier est par défaut en mode minuscule la plupart du temps

2. Parce que tu ne programmes pas seul, et que si quelqu'un reprend
ton prog, c'est une source d'erreur lorsque le pgmr a oublié la
distinction maj/min.

3. Parce que j'ai encore récemment vu un pgmr chevronné faire cette
erreur (utiliser la variable PATH en oubliant qu'elle servait à
quelque chose déjà. (qu'il se dénonce ! ;-) )

4. Parce que la fiabilité d'un programme ne doit pas reposer sur sa
forme d'écriture. En écrivant le maximum de choses en minuscule, on
fait de la PGMD (programmation défensive).

5. Si la règle de PGMD d'utiliser les accolades pour l'utilisation des
variables, le code est lisible, pas besoin de majuscules.


mais on ne peut pas faire boire un âne qui n'a pas soif, alors, codez
comme vous voulez, !


Moi ma référence, c'est la logique et les statistiques, et comme le
disent les bash-kackers:


<citation>
Variable names

Since all reserved variables are UPPERCASE, the safest way is to only
use lowercase variable names. This is true for reading user input,
loop counting variables, etc., … (in the example:file)

<citation>

" the safest way " => "la manière la plus sûre"


Je ne me lancerai pas dans une bataille de référence, mais je reprends
à mon compte l'argument des bash-hackers, basé sur la logique et
l'expérience.


Bref, "code safe, and have fun"


__P
_______________________________________________
Aide mailing list
Aide at lea-linux.org
http://lists.lea-linux.org/listinfo/aide


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lea-linux.org/pipermail/aide/attachments/20160127/978d4914/attachment.html>

Serveur hébergé par ST-Hebergement et Lost-Oasis / IRC hébergé par FreeNode / NS secondaire hébergé par XName
Sauf mention contraire, les documentations publiées sont sous licence Creative-Commons