J'écris systématiquement l'accolade ouvrante et l'accolade fermante
sur une même colonne :
if (condition)
{
action;
}
Cette convention d'écriture me permet de voir immédiatement la
structure en blocs, d'autant que la plupart des éditeurs ont une
couleur spéciale pour les accolades.
Aussi ai-je énormément de mal à lire du code écrit avec l'autre type
de convention :
if (condition) {
action;
}
J'aimerais savoir si les gens qui ont l'habitude des deux conventions,
arrivent à lire aussi facilement la deuxième que la première. Et,
accessoirement, s'il existe des éditeurs capables de mettre les deux
éléments de même "niveau" (i.e. "if (condition) {" et "}") de la même
couleur.
|> On 11 Jun 2004 23:57:19 +0200, James Kanze wrote:
|> >Jamais. Le type va sur une ligne seule. De façon à ce que :
|> > grep ^mafonc *.cc
|> >trouve la définition de la fonction, et que sa définition.
|> N'existe-t-il pas de "grep spécialisé", capable de repérer la |> définition d'une fonction automatiquement, sans imposer ce style ?
On pourrait en écrire sans trop de difficulté, je crois. Être 100% correct exigera parser le C++ complètement, y compris prendre en compte les en-têtes inclus. Mais une expression rationnelle du genre :
^([^ t].*[ t]|^)nomDeFunction(
devrait s'y approcher assez bien dans la plupart des cas.
Mais dans la mésure où j'utilise la convention, et ça depuis au moins vingt ans, et que j'y suis habitué et que je la trouve naturelle, pourquoi m'emmerder.
Note aussi que dans cette perspective, je ne vais pas à la ligne pour le nom dans une declaration de fonction ; j'écris :
extern int f() ;
mais :
int f() { // sa définition... }
Remarque aussi qu'à part les définitions des fonctions, je mets le nom déclaré toujours 20 places à droit de la marge ; je trouve que ça aide à distinguer visuellement ce qui est déclaration, et ce qui est instruction d'expression.
|> Bon, évidemment, j'imagine que ça doit être beaucoup plus facile de |> faire fonctionner un tel programme sur les projets sur lesquels je |> travaille (quelques dizaines de milliers de lignes) que sur les |> tiens... ;-)
Du moment que tu as une expression rationnelle sans renvoie...
Régarde l'implémentation des expressions rationnelles à ma site. Je parie qu'elle laisse celle de Boost loin derrière en ce qui concerne la vitesse. Grace à l'absence du renvoi : qui peut le moins, peut le faire plus vite.
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Fabien LE LEZ <gramster@gramster.com> writes:
|> On 11 Jun 2004 23:57:19 +0200, James Kanze <kanze@gabi-soft.fr> wrote:
|> >Jamais. Le type va sur une ligne seule. De façon à ce que :
|> > grep ^mafonc *.cc
|> >trouve la définition de la fonction, et que sa définition.
|> N'existe-t-il pas de "grep spécialisé", capable de repérer la
|> définition d'une fonction automatiquement, sans imposer ce style ?
On pourrait en écrire sans trop de difficulté, je crois. Être 100%
correct exigera parser le C++ complètement, y compris prendre en compte
les en-têtes inclus. Mais une expression rationnelle du genre :
^([^ t].*[ t]|^)nomDeFunction(
devrait s'y approcher assez bien dans la plupart des cas.
Mais dans la mésure où j'utilise la convention, et ça depuis au moins
vingt ans, et que j'y suis habitué et que je la trouve naturelle,
pourquoi m'emmerder.
Note aussi que dans cette perspective, je ne vais pas à la ligne pour le
nom dans une declaration de fonction ; j'écris :
extern int f() ;
mais :
int
f()
{
// sa définition...
}
Remarque aussi qu'à part les définitions des fonctions, je mets le nom
déclaré toujours 20 places à droit de la marge ; je trouve que ça aide à
distinguer visuellement ce qui est déclaration, et ce qui est
instruction d'expression.
|> Bon, évidemment, j'imagine que ça doit être beaucoup plus facile de
|> faire fonctionner un tel programme sur les projets sur lesquels je
|> travaille (quelques dizaines de milliers de lignes) que sur les
|> tiens... ;-)
Du moment que tu as une expression rationnelle sans renvoie...
Régarde l'implémentation des expressions rationnelles à ma site. Je
parie qu'elle laisse celle de Boost loin derrière en ce qui concerne la
vitesse. Grace à l'absence du renvoi : qui peut le moins, peut le faire
plus vite.
--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
|> On 11 Jun 2004 23:57:19 +0200, James Kanze wrote:
|> >Jamais. Le type va sur une ligne seule. De façon à ce que :
|> > grep ^mafonc *.cc
|> >trouve la définition de la fonction, et que sa définition.
|> N'existe-t-il pas de "grep spécialisé", capable de repérer la |> définition d'une fonction automatiquement, sans imposer ce style ?
On pourrait en écrire sans trop de difficulté, je crois. Être 100% correct exigera parser le C++ complètement, y compris prendre en compte les en-têtes inclus. Mais une expression rationnelle du genre :
^([^ t].*[ t]|^)nomDeFunction(
devrait s'y approcher assez bien dans la plupart des cas.
Mais dans la mésure où j'utilise la convention, et ça depuis au moins vingt ans, et que j'y suis habitué et que je la trouve naturelle, pourquoi m'emmerder.
Note aussi que dans cette perspective, je ne vais pas à la ligne pour le nom dans une declaration de fonction ; j'écris :
extern int f() ;
mais :
int f() { // sa définition... }
Remarque aussi qu'à part les définitions des fonctions, je mets le nom déclaré toujours 20 places à droit de la marge ; je trouve que ça aide à distinguer visuellement ce qui est déclaration, et ce qui est instruction d'expression.
|> Bon, évidemment, j'imagine que ça doit être beaucoup plus facile de |> faire fonctionner un tel programme sur les projets sur lesquels je |> travaille (quelques dizaines de milliers de lignes) que sur les |> tiens... ;-)
Du moment que tu as une expression rationnelle sans renvoie...
Régarde l'implémentation des expressions rationnelles à ma site. Je parie qu'elle laisse celle de Boost loin derrière en ce qui concerne la vitesse. Grace à l'absence du renvoi : qui peut le moins, peut le faire plus vite.
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
James Kanze
Fabien LE LEZ writes:
|> On Sat, 12 Jun 2004 12:33:28 -0400, "Michel Michaud" |> wrote:
|> > if ( SoldCount > 1000 ) then begin |> > Markdown := 0.10; |> > Profit := 0.05 |> > end |> > else Markdown := 0.05;
|> >Cet exemple est décrit par « A rare Pascal example example in which |> >endline layout works acceptably ».
Comme il dit, un exemple rare où il fonctionne.
|> Arf... C'est le genre de méthode qui marche bien si tu as un écran |> très très large...
Ou des expressions très, très simple, et les noms de variables et de fonction très courts.
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Fabien LE LEZ <gramster@gramster.com> writes:
|> On Sat, 12 Jun 2004 12:33:28 -0400, "Michel Michaud" <mm@gdzid.com>
|> wrote:
|> > if ( SoldCount > 1000 ) then begin
|> > Markdown := 0.10;
|> > Profit := 0.05
|> > end
|> > else Markdown := 0.05;
|> >Cet exemple est décrit par « A rare Pascal example example in which
|> >endline layout works acceptably ».
Comme il dit, un exemple rare où il fonctionne.
|> Arf... C'est le genre de méthode qui marche bien si tu as un écran
|> très très large...
Ou des expressions très, très simple, et les noms de variables et de
fonction très courts.
--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
|> On Sat, 12 Jun 2004 12:33:28 -0400, "Michel Michaud" |> wrote:
|> > if ( SoldCount > 1000 ) then begin |> > Markdown := 0.10; |> > Profit := 0.05 |> > end |> > else Markdown := 0.05;
|> >Cet exemple est décrit par « A rare Pascal example example in which |> >endline layout works acceptably ».
Comme il dit, un exemple rare où il fonctionne.
|> Arf... C'est le genre de méthode qui marche bien si tu as un écran |> très très large...
Ou des expressions très, très simple, et les noms de variables et de fonction très courts.
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
James Kanze
Fabien LE LEZ writes:
|> On 12 Jun 2004 00:08:06 +0200, James Kanze wrote:
|> Dans des cas comme ça, tu as la possibilité de passer une moulinette |> sur le code pour y rajouter une indentation ?
Dans le cas réel où c'est présenté, le langage n'était pas C ni C++, mais PL/M, et je n'avais pas le moindre possibilité. Dans le cas d'un langage courant, aujourd'hui, évidemment, c'est la première chose que j'aurais fait : ^x H M-Q sous emacs, ou 1GVGgq sous vim.
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Fabien LE LEZ <gramster@gramster.com> writes:
|> On 12 Jun 2004 00:08:06 +0200, James Kanze <kanze@gabi-soft.fr> wrote:
|> Dans des cas comme ça, tu as la possibilité de passer une moulinette
|> sur le code pour y rajouter une indentation ?
Dans le cas réel où c'est présenté, le langage n'était pas C ni C++,
mais PL/M, et je n'avais pas le moindre possibilité. Dans le cas d'un
langage courant, aujourd'hui, évidemment, c'est la première chose que
j'aurais fait : ^x H M-Q sous emacs, ou 1GVGgq sous vim.
--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
|> Dans des cas comme ça, tu as la possibilité de passer une moulinette |> sur le code pour y rajouter une indentation ?
Dans le cas réel où c'est présenté, le langage n'était pas C ni C++, mais PL/M, et je n'avais pas le moindre possibilité. Dans le cas d'un langage courant, aujourd'hui, évidemment, c'est la première chose que j'aurais fait : ^x H M-Q sous emacs, ou 1GVGgq sous vim.
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
drkm
James Kanze writes:
Fabien LE LEZ writes:
|> Dans des cas comme ça, tu as la possibilité de passer une moulinette |> sur le code pour y rajouter une indentation ?
Dans le cas réel où c'est présenté, le langage n'était pas C ni C++, mais PL/M, et je n'avais pas le moindre possibilité. Dans le cas d'un langage courant, aujourd'hui, évidemment, c'est la première chose que j'aurais fait : ^x H M-Q sous emacs, ou 1GVGgq sous vim.
Tu veux dire C-x h C-M-, je suppose. C-x h M-q, à part réindenter tes commentaires en tête de fichier, ... À moins bien sûr de n'avoir modifié le binding standard de M-q. Ce qui m'étonnerais de toi :-).
--drkm
James Kanze <kanze@gabi-soft.fr> writes:
Fabien LE LEZ <gramster@gramster.com> writes:
|> Dans des cas comme ça, tu as la possibilité de passer une moulinette
|> sur le code pour y rajouter une indentation ?
Dans le cas réel où c'est présenté, le langage n'était pas C ni C++,
mais PL/M, et je n'avais pas le moindre possibilité. Dans le cas d'un
langage courant, aujourd'hui, évidemment, c'est la première chose que
j'aurais fait : ^x H M-Q sous emacs, ou 1GVGgq sous vim.
Tu veux dire C-x h C-M-, je suppose. C-x h M-q, à part réindenter
tes commentaires en tête de fichier, ... À moins bien sûr de n'avoir
modifié le binding standard de M-q. Ce qui m'étonnerais de toi :-).
|> Dans des cas comme ça, tu as la possibilité de passer une moulinette |> sur le code pour y rajouter une indentation ?
Dans le cas réel où c'est présenté, le langage n'était pas C ni C++, mais PL/M, et je n'avais pas le moindre possibilité. Dans le cas d'un langage courant, aujourd'hui, évidemment, c'est la première chose que j'aurais fait : ^x H M-Q sous emacs, ou 1GVGgq sous vim.
Tu veux dire C-x h C-M-, je suppose. C-x h M-q, à part réindenter tes commentaires en tête de fichier, ... À moins bien sûr de n'avoir modifié le binding standard de M-q. Ce qui m'étonnerais de toi :-).
--drkm
James Kanze
drkm writes:
|> James Kanze writes:
|> > Fabien LE LEZ writes:
|> > |> Dans des cas comme ça, tu as la possibilité de passer une |> > |> moulinette sur le code pour y rajouter une indentation ?
|> > Dans le cas réel où c'est présenté, le langage n'était pas C ni |> > C++, mais PL/M, et je n'avais pas le moindre possibilité. Dans le |> > cas d'un langage courant, aujourd'hui, évidemment, c'est la |> > première chose que j'aurais fait : ^x H M-Q sous emacs, ou 1GVGgq |> > sous vim.
|> Tu veux dire C-x h C-M-, je suppose. C-x h M-q, à part réindenter |> tes commentaires en tête de fichier, ... À moins bien sûr de n'avoir |> modifié le binding standard de M-q. Ce qui m'étonnerais de toi :-).
À vrai dire, je ne me rappelle plus exactement, parce que j'utilise vim pour le développement du code:-). Mais je n'ai pas modifier les binding standard.
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
drkm <usenet.fclcxx@fgeorges.org> writes:
|> James Kanze <kanze@gabi-soft.fr> writes:
|> > Fabien LE LEZ <gramster@gramster.com> writes:
|> > |> Dans des cas comme ça, tu as la possibilité de passer une
|> > |> moulinette sur le code pour y rajouter une indentation ?
|> > Dans le cas réel où c'est présenté, le langage n'était pas C ni
|> > C++, mais PL/M, et je n'avais pas le moindre possibilité. Dans le
|> > cas d'un langage courant, aujourd'hui, évidemment, c'est la
|> > première chose que j'aurais fait : ^x H M-Q sous emacs, ou 1GVGgq
|> > sous vim.
|> Tu veux dire C-x h C-M-, je suppose. C-x h M-q, à part réindenter
|> tes commentaires en tête de fichier, ... À moins bien sûr de n'avoir
|> modifié le binding standard de M-q. Ce qui m'étonnerais de toi :-).
À vrai dire, je ne me rappelle plus exactement, parce que j'utilise vim
pour le développement du code:-). Mais je n'ai pas modifier les binding
standard.
--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
|> > |> Dans des cas comme ça, tu as la possibilité de passer une |> > |> moulinette sur le code pour y rajouter une indentation ?
|> > Dans le cas réel où c'est présenté, le langage n'était pas C ni |> > C++, mais PL/M, et je n'avais pas le moindre possibilité. Dans le |> > cas d'un langage courant, aujourd'hui, évidemment, c'est la |> > première chose que j'aurais fait : ^x H M-Q sous emacs, ou 1GVGgq |> > sous vim.
|> Tu veux dire C-x h C-M-, je suppose. C-x h M-q, à part réindenter |> tes commentaires en tête de fichier, ... À moins bien sûr de n'avoir |> modifié le binding standard de M-q. Ce qui m'étonnerais de toi :-).
À vrai dire, je ne me rappelle plus exactement, parce que j'utilise vim pour le développement du code:-). Mais je n'ai pas modifier les binding standard.
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Fabien LE LEZ
possibilité
Par "possibilité", j'entendais plutôt "autorisation", en référence par exemple à <news:caaikg$ggs$
-- ;-)
possibilité
Par "possibilité", j'entendais plutôt "autorisation", en référence par
exemple à <news:caaikg$ggs$1@news-reader1.wanadoo.fr>
Par "possibilité", j'entendais plutôt "autorisation", en référence par exemple à <news:caaikg$ggs$
-- ;-)
Gabriel Dos Reis
James Kanze writes:
| Gabriel Dos Reis writes: | | |> James Kanze writes: | | |> | Gabriel Dos Reis writes: | | |> | |> James Kanze writes: | | |> | |> | BlueR writes: | | |> | |> | |> Je suis aussi cette disposition, et éventuellement s'il | |> | |> | |> y a plus de 3-4 blocs imbriqués et que je commence à y | |> | |> | |> voir moins clair je rajoute un commentaire sur | |> | |> | |> l'accolade fermante. | | |> | |> | S'il y a 3 ou 4 blocs imbriqués, la fonction est trop compliquée. | | |> | |> Je suppose que tu as laissé tomber l'utilisation des classes | |> | |> locales ? ;-) | | |> | Pas le choix. Les auteurs de la norme à décider qu'elles ne | |> | marchent pas complètement. (Neuf fois sur dix, quand je veux une | |> | classe locale, c'est pour instantier un template.) | | |> Mais et avant ? | | Et avant ? Je n'avais pas tant de classes locales que ça. En général, | les seuls cas auxquels je me souviens d'avoir utiliser une classe | locale, c'est quand c'était pour ainsi dire la seule chose dans la | fonction. C-à-d des fonctions usine, dont la seule instruction était | « return new ClasseLocale ; ». Et avec une classe qui ne dépassait pas | une dizaine de lignes.
donc tu avais au moins 3 blocs imbriqués. :-)
OK, je retourne me coucher.
-- Gaby
James Kanze <kanze@gabi-soft.fr> writes:
| Gabriel Dos Reis <gdr@cs.tamu.edu> writes:
|
| |> James Kanze <kanze@gabi-soft.fr> writes:
|
| |> | Gabriel Dos Reis <gdr@cs.tamu.edu> writes:
|
| |> | |> James Kanze <kanze@gabi-soft.fr> writes:
|
| |> | |> | BlueR <blueremi@free.fr_supprimer_> writes:
|
| |> | |> | |> Je suis aussi cette disposition, et éventuellement s'il
| |> | |> | |> y a plus de 3-4 blocs imbriqués et que je commence à y
| |> | |> | |> voir moins clair je rajoute un commentaire sur
| |> | |> | |> l'accolade fermante.
|
| |> | |> | S'il y a 3 ou 4 blocs imbriqués, la fonction est trop compliquée.
|
| |> | |> Je suppose que tu as laissé tomber l'utilisation des classes
| |> | |> locales ? ;-)
|
| |> | Pas le choix. Les auteurs de la norme à décider qu'elles ne
| |> | marchent pas complètement. (Neuf fois sur dix, quand je veux une
| |> | classe locale, c'est pour instantier un template.)
|
| |> Mais et avant ?
|
| Et avant ? Je n'avais pas tant de classes locales que ça. En général,
| les seuls cas auxquels je me souviens d'avoir utiliser une classe
| locale, c'est quand c'était pour ainsi dire la seule chose dans la
| fonction. C-à-d des fonctions usine, dont la seule instruction était
| « return new ClasseLocale ; ». Et avec une classe qui ne dépassait pas
| une dizaine de lignes.
| Gabriel Dos Reis writes: | | |> James Kanze writes: | | |> | Gabriel Dos Reis writes: | | |> | |> James Kanze writes: | | |> | |> | BlueR writes: | | |> | |> | |> Je suis aussi cette disposition, et éventuellement s'il | |> | |> | |> y a plus de 3-4 blocs imbriqués et que je commence à y | |> | |> | |> voir moins clair je rajoute un commentaire sur | |> | |> | |> l'accolade fermante. | | |> | |> | S'il y a 3 ou 4 blocs imbriqués, la fonction est trop compliquée. | | |> | |> Je suppose que tu as laissé tomber l'utilisation des classes | |> | |> locales ? ;-) | | |> | Pas le choix. Les auteurs de la norme à décider qu'elles ne | |> | marchent pas complètement. (Neuf fois sur dix, quand je veux une | |> | classe locale, c'est pour instantier un template.) | | |> Mais et avant ? | | Et avant ? Je n'avais pas tant de classes locales que ça. En général, | les seuls cas auxquels je me souviens d'avoir utiliser une classe | locale, c'est quand c'était pour ainsi dire la seule chose dans la | fonction. C-à-d des fonctions usine, dont la seule instruction était | « return new ClasseLocale ; ». Et avec une classe qui ne dépassait pas | une dizaine de lignes.
donc tu avais au moins 3 blocs imbriqués. :-)
OK, je retourne me coucher.
-- Gaby
Gabriel Dos Reis
Fabien LE LEZ writes:
| On Mon, 14 Jun 2004 15:41:23 +0200, "Mickael Pointier" | : | | >je ne supporte pas les ";" | | Ben... dans un langage aussi complexe que le C++, il faut un caractère | spécial pour séparer les instructions, sinon le pov' compilateur | aurait bien du mal à s'y retrouver.
Je ne sais pas. C'est pas C++ qui a inventé les « ; » comme fin d'instruction -- contrairement à Pascal et derivés qui l'utilisent comme séparateur.
Lorsque C++ a introduit les « namespaces » -- que nombre de programmeurs décrivent comme complexes -- les « ; » n'étaient pas nécessaires pour marquer la fin de définition d'un namespace -- contrairement aux structs de C.
-- Gaby
Fabien LE LEZ <gramster@gramster.com> writes:
| On Mon, 14 Jun 2004 15:41:23 +0200, "Mickael Pointier"
| <mpointier@edengames.moc>:
|
| >je ne supporte pas les ";"
|
| Ben... dans un langage aussi complexe que le C++, il faut un caractère
| spécial pour séparer les instructions, sinon le pov' compilateur
| aurait bien du mal à s'y retrouver.
Je ne sais pas. C'est pas C++ qui a inventé les « ; » comme fin
d'instruction -- contrairement à Pascal et derivés qui l'utilisent
comme séparateur.
Lorsque C++ a introduit les « namespaces » -- que nombre de
programmeurs décrivent comme complexes -- les « ; » n'étaient pas
nécessaires pour marquer la fin de définition d'un namespace --
contrairement aux structs de C.
| On Mon, 14 Jun 2004 15:41:23 +0200, "Mickael Pointier" | : | | >je ne supporte pas les ";" | | Ben... dans un langage aussi complexe que le C++, il faut un caractère | spécial pour séparer les instructions, sinon le pov' compilateur | aurait bien du mal à s'y retrouver.
Je ne sais pas. C'est pas C++ qui a inventé les « ; » comme fin d'instruction -- contrairement à Pascal et derivés qui l'utilisent comme séparateur.
Lorsque C++ a introduit les « namespaces » -- que nombre de programmeurs décrivent comme complexes -- les « ; » n'étaient pas nécessaires pour marquer la fin de définition d'un namespace -- contrairement aux structs de C.
-- Gaby
drkm
Fabien LE LEZ writes:
possibilité
Par "possibilité", j'entendais plutôt "autorisation", en référence par exemple à <news:caaikg$ggs$
Ok.
Il y a alors moyen, s'il n'a pas le droit de modifier l'indentation du projet, je modifier le « reindenter » ci-dessus pour qu'il enregistre le fichier formaté sous une autre extension. Et il existe un mode pour afficher deux fichiers en vis-à-vis, les déplacements dans l'un impliquant les mêmes déplacements dans l'autre.
Ce qui permet de travailler sur le fichier non formaté à gauche, avec à droite l'équivalent formatté. Ce n'est pas parfait, mais avec le genre de code que James a donné (d'où est parti ce sous-fil), dans le cas où il ne peut réindenter les sources officielles, il me semble dur de faire mieux.
J'espère ne jamais devoir reprendre un tel code ...
--drkm
Fabien LE LEZ <gramster@gramster.com> writes:
possibilité
Par "possibilité", j'entendais plutôt "autorisation", en référence par
exemple à <news:caaikg$ggs$1@news-reader1.wanadoo.fr>
Ok.
Il y a alors moyen, s'il n'a pas le droit de modifier l'indentation
du projet, je modifier le « reindenter » ci-dessus pour qu'il
enregistre le fichier formaté sous une autre extension. Et il existe
un mode pour afficher deux fichiers en vis-à-vis, les déplacements
dans l'un impliquant les mêmes déplacements dans l'autre.
Ce qui permet de travailler sur le fichier non formaté à gauche,
avec à droite l'équivalent formatté. Ce n'est pas parfait, mais avec
le genre de code que James a donné (d'où est parti ce sous-fil), dans
le cas où il ne peut réindenter les sources officielles, il me semble
dur de faire mieux.
J'espère ne jamais devoir reprendre un tel code ...
Par "possibilité", j'entendais plutôt "autorisation", en référence par exemple à <news:caaikg$ggs$
Ok.
Il y a alors moyen, s'il n'a pas le droit de modifier l'indentation du projet, je modifier le « reindenter » ci-dessus pour qu'il enregistre le fichier formaté sous une autre extension. Et il existe un mode pour afficher deux fichiers en vis-à-vis, les déplacements dans l'un impliquant les mêmes déplacements dans l'autre.
Ce qui permet de travailler sur le fichier non formaté à gauche, avec à droite l'équivalent formatté. Ce n'est pas parfait, mais avec le genre de code que James a donné (d'où est parti ce sous-fil), dans le cas où il ne peut réindenter les sources officielles, il me semble dur de faire mieux.
J'espère ne jamais devoir reprendre un tel code ...
--drkm
Fabien LE LEZ
On 12 Jun 2004 00:08:06 +0200, James Kanze :
Ou même une fois, une indentation aléatoire, y compris (une fois au moins) :
if ( condition ) quelqueChose ; autreChose ; etEncore ;
En-dehors de l'IOCCC ?
-- schtroumpf schtroumpf
On 12 Jun 2004 00:08:06 +0200, James Kanze <kanze@gabi-soft.fr>:
Ou même une fois, une indentation aléatoire, y compris (une fois au
moins) :
if ( condition )
quelqueChose ;
autreChose ;
etEncore ;
