French Pourquoi aucune entête et presque aucun commentaire dans un prog. B4A ?

P

PicTech

Member
Licensed User
Longtime User
Bonjour tout l'monde,

Je suis de la vieille école de la programmation en C ou en Basic ou même en assembleur où on fait habituellement une entête grosse comme l'écran avec aussi pleins de commentaires dans notre code pour retrouver nos procédures plus facilement.

Pourquoi je ne vois rien de tout ça dans les programmes B4A?

Est-ce un problème pour le compilateur? Ordinairement les commentaires sont ignorés et ça ne grossit pas le code compilé.

Prochaine,
Richard.
 
Informatix

Informatix

Expert
Licensed User
Longtime User
PicTech said:
Bonjour tout l'monde,

Je suis de la vieille école de la programmation en C ou en Basic ou même en assembleur où on fait habituellement une entête grosse comme l'écran avec aussi pleins de commentaires dans notre code pour retrouver nos procédures plus facilement.

Pourquoi je ne vois rien de tout ça dans les programmes B4A?

Est-ce un problème pour le compilateur? Ordinairement les commentaires sont ignorés et ça ne grossit pas le code compilé.

Prochaine,
Richard.
Click to expand...

Les gens sont sans doute trop feignants pour en mettre en dehors de leurs propres applications (moi par exemple). :)
Ca n'a rien à voir avec le compilateur en tous cas.
Pendant deux ans, mon boulot a consisté à réécrire ou corriger des programmes écrits par des prestataires de service et j'ai donc vu toutes sortes de façon de commenter par toutes sortes de personne. Les commentaires les plus longs ne sont pas forcément les plus utiles, mais bon, c'est mieux qu'un grand désert. Ca ne sert à rien par exemple de mettre des commentaires pour une fonction qui fait juste "return MyVar.MyProp + 1", ou de raconter en long et en large ce que fait une fonction qui ne recourt à aucun algorithme particulier (par exemple, dans une fonction qui aligne les assignations de variables, ce sont les valeurs choisies qui méritent un commentaire, pas le rôle de la fonction).
Le plus important à mes yeux, ce sont des variables explicites, des fonctions groupées par famille et par ordre d'appel, des paramètres de fonction bien expliqués, des petits commentaires qui expliquent pourquoi le programmeur a du faire ça de cette façon, une explicitation systématique des constantes numériques, des programmes de tests...
Je n'arrive pas à comprendre les gars qui pondent des bibliothèques pour B4A et qui ne font ni programme de démo ni tutoriel (ce qui est indispensable vu que l'on n'a pas accès à leur code Java). Le gars qui a fait xnGrid par exemple. Je n'ai pas encore trouvé l'envie d'essayer son travail.
Dans mon cadre professionnel, on fait plus que commenter les programmes. On écrit de véritables dossiers. C'est tellement pénible que j'ai beaucoup de mal à faire ça dans mon code B4A. Et franchement le niveau algorithmique de la plupart du code que je ponds avec B4A est tellement proche de 0 que je ne risque pas d'être perdu en relisant mon code 6 mois plus tard. C'est peut-être pareil pour d'autres.

Salutations,
Fred
 
P

PicTech

Member
Licensed User
Longtime User
Informatix said:
Les gens sont sans doute trop feignants pour en mettre en dehors de leurs propres applications
Click to expand...

Salut mon ami!

Tu es d'une générosité incroyable, je suis impressionné d'avoir tomber sur un gars comme toi. Merci pour cette grande réponse, ça confirme ce que je pensais.

Je trouve que c'est encore plus important d'ajouter des commentaires dans notre programme quand c'est justement pour partager nos idées dans un forum comme ici. Ça aide les autres à beaucoup mieux comprendre et ça évite bien des questions inutiles.

Amitié,
Richard.
 
klaus

klaus

Expert
Licensed User
Longtime User
Salut,
Je viens aussi mettre mon grain de sel.
Je suis entièrement d'accord avec Fred trop de commentaires tuent les commentaires.
Personnellement je suis avare de commentaires sauf s'il y a des particularités qui peuvent prêter à confusion.
Pour moi le plus important ce sont des noms d'objets et de variables significatifs avec un préfixe désignant le type d'objet.
Un code aéré avec des lignes vierges séparant les différentes parties d'une routine et avec une identation systématique. Et des routines courtes.
Sous cette forme, dans la majorité des cas, le code s'explique par lui même.
Mais bon, chacun a sa manière de coder.

Meilleures salutations.
 
P

PicTech

Member
Licensed User
Longtime User
Bonjour Klaus,

klaus said:
Salut,
Je viens aussi mettre mon grain de sel.
Click to expand...

Super! Je commençais à penser qu'on étaient juste deux...

Comme dit notre slogan de la SAQ (Société des Alcools du Québec), "La modération a bien meilleur goût". :)

Je suis 100% d'accord avec ta méthode, c'est ce que je fais aussi mais avec un peu plus. J'aime bien ajouter une entête explicite avec: Auteur, nom du prog, date, compilateur utilisé, fichier ext requis et une petite description. J'ajoute aussi une grosse ligne de séparation entre ma section "Déclaration des variables", procédures, groupe de fonctions et le programme principal. Quand tu as 10 pages de long, ça aide beaucoup à s'y retrouver.

Mais pour te faire plaisir, je ne suis pas du genre à écrire:
A = 2 ' Assignation de la valeur "2" à la variable "A"

C'est vrai que ça fait lourd pour pas dire plutôt bébé!

Voici un exemple. J'utilise les lignes de commentaires beaucoup plus pour séparer que pour expliquer.



B4X: 
/*****************************************************************

 NOM   :  16F1825-SPI-SPI-RS232-05 (Slave)
 Date  :  15-03-2012
 Auteur:  SCE Technologie (C)2012

******************************************************************

 Essais Master-Slave avec deux 16F1825 en SPI

 Test de base sonde TC77 vers SPI vers autre MCU SPI vers RS232

 Réception de 4 octets du Master pour adresse et température
 et revoie de 4 octets en réponse avec ma température

 RS232 = 115200 bauds
 SPI = 1 MHz = 1 Mbits/s

******************************************************************

 CMP: MikroElektronika mikroC PRO v5.40
 MCU: 16F1825
 Cristal: 20 MHz
 Horloge: 16 MHz

 Fichier requis:

*****************************************************************/

// Variables

sbit Slave_Select at RC3_bit;
sbit Slave_Select_Direction at TRISC3_bit;
char Octet_Reception[4];
char Octet_Emission[4];
char buffer;

sbit Led1       at RA2_bit;            // Assignation patte LED

//**************************************************************************************************
// Initialisation
//**************************************************************************************************
void Init_Main()
{
    OSCCON = 0b01111101;               // Mode oscillateur interne à 16 MHz
    ANSELA = 0b00000000;               // Port en mode digital
    ANSELC = 0b00000000;               // Port en mode digital
    TRISA = 0b00000000;                // Port en sortie
    TRISC = 0b00101010;                // Port en sortie sauf C1 C3 C5

    // Initialise le module SPI en mode *** SLAVE ***
    SPI1_Init_Advanced(_SPI_SLAVE_SS_ENABLE, _SPI_DATA_SAMPLE_MIDDLE, _SPI_CLK_IDLE_LOW, _SPI_LOW_2_HIGH);

    // Initialise le module UART
    UART1_Init(115200);
    Delay_ms(100);                     // Stabilisation de l'UART

}

//**************************************************************************************************
//     *** PROGRAMME PRINCIPAL ***
//**************************************************************************************************

void main() {

    Init_Main();                       // Initialisation principale

    Octet_Emission[0] = 5;
    Octet_Emission[1] = 6;
    Octet_Emission[2] = 7;
    Octet_Emission[3] = 8;

//**************************************************************************************************
// Boucles de réception sur le port SPI
//**************************************************************************************************

    while (1){

            // Réception de la trame SPI
            if (Slave_Select) {    // Si réception

                    Octet_Reception[0] = SPI1_Read(buffer);          // Adresse
                    Octet_Reception[1] = SPI1_Read(buffer);
                    Octet_Reception[2] = SPI1_Read(buffer);          // Température
                    Octet_Reception[3] = SPI1_Read(buffer);
                   
            Led1 = 1;
            Delay_ms(50);
            Led1 = 0;
        }
    }
}

//******************************** FIN DU PROGRAMME ************************************************

P.S. L'auteur décline toutes responsabilités pour l'utilisation de ce code avec votre téléphone! :signOops:

Prochaine,
Richard.
 
L

logemag

Member
Licensed User
Longtime User
bonjour, je me permets aussi d'apporter un petit plus à ce post, pour les commentaires j'avoue que j'ai souvent la flemme d'en rajouter, et pourtant quand on relit quelques mois plus tard un bout de code que l'on doit retravailler, on ne se souvient plus très bien pour qu'elle raison on a fait certaines choses. C'est souvent perdre du temps que de retrouver le pourquoi du comment...

Maintenant je 'rem' souvent les procédures pour plus de lisibilité d'auto-complete grâce à la nouvelle version 2.0 de B4A. Super d'ailleurs même s'il arrive qu'ils ne s'affichent plus de temps en temps sans savoir pourquoi, mais ça c'est un autre problème.

Depuis quelques temps je m'oblige à ajouter des commentaires car mon associé, qui rechignait à tester B4A commence à envisager de nous faire acheter une licence pour lui. je sais qu'il mettra bien, un jour ou l'autre, le nez dans mes codes donc je lui simplifie un peu la vie... Comme vous, je ne commente pas de choses insignifiantes comme des string ou des des int en local, mais je prends le temps de commenter une var globale, là encore grâce au F7, on se simplifie la vie à retrouver facilement le cheminement et le commentaire de la var... Tous les outils qui sont mis à disposition dans ce soft, du débugger, au logage en passant par la recherche de références, nous aident précieusement à avancer dans nos projets...

En parlant du logage, je pense que je mets d'ailleurs plus souvent de log("que devient DblePRIX ? : " & DblePRIX) que je mets en commentaires ensuite, mais au moins je sais qu'à un moment j'avais besoin de voir en live cette var pour une raison déterminée... Il me reste qu'à enlever le commentaire et connecter le logage pour en vérifier sa valeur...

Pour finir, je n'ai aucune formation particulière en informatique, donc je n'ai pas les bases 'scolaires' des techniques de programmation, par contre il m'arrive souvent de faire de petits organigrammes pour visualiser ce qu'il doit se passer et comment ça doit être, mais il est vrai que plus on complexifie son projet plus la valeur d'une VAR peux changer ou évoluer, d'où les logs indispensables !

Le nom d'une variable ou d'une procédure aussi va nous aider à mieux visualiser de quoi il retourne, je le faisais pas trop au départ, du style VAR1, VAR2, mais maintenant je m’efforce de bien indiquer sa fonction et son rang : StrDesignation, IntIdx ou DblePrix, ça aussi ça aide !

Voilà, j'ai pas dû réinventer la roue, ni vous en apprendre plus, mais il est vrai que bien détailler son code, le structurer, créer de petites subs bien nommées (par exemple : sub Calcul_Prix et sub Calcul_Nbre_Item, vaut mieux que sub SUITE1, sub SUITE2) au lieu de grandes procédures non détaillés, aident vraiment déjà à la lisibilité du code...

best regards, Guillaume
 
You must log in or register to reply here.
Top