[F] [mOved] Mon langage est mieux que le tien - Page 71

AlignTrailingComments (bool)

(merci, mais je parle d'eclipse ^^)

nope nope nope

struct gl_widget;
typedef struct gl_widget
    {
    unsigned short    type;        // Internal type
    struct gl_widget* parent;      // Parent widget
    short             x;           // Absolute position on the screen. Computed at drawing time (DrawWidget())
    short             y;           //
    short             width;       // Dimensions. Computed at preparation time (PrepareWidget())
    short             height;      //
    bool              dirty;       // True if the dimensions of the widget must be computed before drawing.
    short             alignment;   // Graphical aligment in the parent layout
    bool              enabled;     // True if the widget is displayed in normal mode and executable
} gl_widget;

Ah oui, on peut aussi, je prends note de régler ça

squalyl (./2103) :
struct gl_widget* parent; // Parent widget

Ça, c'est pas beau.

Sinon sans utilise clang il y a astyle :

http://astyle.sourceforge.net

Très configurable supporte plein de languages

J'ai essayé souvent astyle, au fil de ses évolutions, et ce n'est pas aussi paramétrable que clang-format, loin s'en faut.

Personnellement, je déteste les formatteurs automatiques, aucun n'est capable de reproduire exactement mon style.

Tu n'as plus qu'à écrire Kstyle

pas terrible. C'est beaucoup mieux de respecter une norme bien classique quand tu travailles avec du monde…

C'est un des points forts de Python () à mes yeux : tout le monde (ou presque) respecte la même norme de code (PEP008), c'est beaucoup plus agréable quand on se plonge dans le code d'un autre.

(Kevin > ton style en asm était assez facile à reproduire )

(et son style en C est tellement "personnel" que personne ne doit vouloir le reproduire )

(Déjà pour écrire les indices à l'envers, il faut une certaine puissance du formatter )

Pen^2 (./2094) :
Pas mal cette feature d'alignement, c'est quelque chose que je ne fais pas parce que c'est trop pénible à maintenir. Je suis jaloux

C'est un style que j'aime bien parce qu'à un instant donné c'est visuellement agréable mais je ne le fais plus, parce que ça veut dire potentiellement générer un diff de plein de lignes quand on ajoute ou supprime un champ dans une structure, juste parce qu'il faut décaler tous les autres commentaires autour. Du coup ça fout la merde dans la gestion de version, ça ajoute des fausses infos dans les outils genre git blame, ça génère potentiellement des conflits de merge/rebase pour rien, etc. Finalement c'est trop cher payé pour un petit confort visuel je trouve.

On est d'accord. Je propose de slapper Folco.

Zeph > ton diff prend en compte les espaces/tabulations non significatifs ?

Bien sûr, il n'a aucune connaissance du langage donc aucune façon de savoir quelle indentation est la "mieux" (ni même de savoir si les espaces ont une importance dans ton langage ou non). Il n'y a que dans un outil de diff visuel que tu peux te permettre de les ignorer (ou plutôt, comme souvent, de les marquer de façon moins vive) mais pas dans un outil de résolution de conflit qui se veut agnostique.

Tiens, j'ai pas eu l'occasion d'utiliser Git, mais il me semble qu'à l'époque où j'utilisais TortoiseSVN + Araxis Merge au boulot, ce genre de cas était géré au moins pour les sources en C++. Après, ce n'est pas moi qui avait fait la config, et c'était il y a plusieurs années donc peut-être que je raconte des bêtises.

C'est desactivable et de toutes manière git s'en fout il stock le fichier entier pas des diffs.

Les diff/blame sont génèré à la volée et on peu ignorer les espaces non significatifs

OK, tu m'envoies la config Git qui permet d'ignorer les changements provoqués par la coding style de Folco ? (sans installer d'outil supplémentaire bien sûr)

Je te renvois vers la doc de diff. Je suis désolé je n'ai pas les moyens de regarder la de suite je regarderais et posterais demain sauf si qu'un à donne la réponse entre temps.

Si tu penses aux options pour changer l'interprétation des whitespaces dans Git ou à diff -b je pense que ça ne résout pas du tout le problème que j'évoque : les espaces en +/- ne sont pas en fin de ligne, ni en fin de fichier (et c'est un problème de versionning hein, pas juste de diff : même si tu peux ignorer certaines différences entre deux fichiers à l'affichage, tu vas quand même provoquer une nouvelle version à cause de lignes changées par des ajouts ou suppression d'espaces).

Pas d'offense, mais je ne suis pas sur de comprendre le problème.

Si:

- tu fais des changements dans le fichier qui induisent en plus des changements dans les white spaces ignorer les différences de white space lors d'un diff/blame est ce que tu veux, ça ne changera pas la façon dont git sauvegarde le fichier en interne, il garde le fichier entier et pas juste un diff avec la version précédente.

- c'est juste des changements cosmétiques et que tu ne veux pas que ça soit un commit a par entière il y a une solution simple avec git: réécriture de l'historique, c'est fait pour ça.

Sinon je vois vraiment pas de quoi tu veux parler..

Oh ha si et diff est tout a fait capable de ne pas prendre en compte comment tu indente ton code, 2,3,4,20 espaces ou 42 tabs si tu lui dit d'ignorer les white space c'est pas uniquement en fin de ligne et les lignes vides. C'est aussi en début et les potentielles répétitions d'espaces séquentielles.

Tain il pootr CLion. Il n'est peut être pas si simple à utiliser pour un débutant (j'ai dû apprendre Cmake, mais je ne l'ai pas fait pour lui, j'avais déjà eu besoin avant parce que j'ai essayé comme un malade de faire marcher le plugin EasyClangComplete pour SublimeText ainsi qu'un équivalent pour vim mais c'est juste de la merde, il cesse de fonctionner aléatoirement, garde des machins en cache je sais pas où, et quand ça marche plus ça marche plus).

Donc voilà une fois que t'as créé ton CmakeLists.txt il prend tout en charge. Et tu te retrouves à coder en C++ juste comme tu le ferais en Java : refactoring qui poutre et marche, navigation instantanée (et indexation qui marche !) dans toutes les parties du projet, recherche textuelle avec classification (strings, comments, etc.), suggestions (popup) instantanées et utiles, tout sort instantanément, les erreurs sont en rouge, les symboles (même les #include et tout) sont en gris lorsqu'ils ne sont pas utilisés, tu peux faire du cleanup instantané, les commentaires doxygen générés en un /**, débogage graphique et j'en passe encore des tas (je vais sûrement en rajouter à mesure que je découvre). C'est vraiment incroyable ce qu'ils ont fait.

Sinon rien à voir mais j'ai installé une appli pomodoro pour gnome et le machin vient de me sonner à la gueule en me disant "hey, concentre toi sur ta tâche" lol, on dirait qu'il considère pas malin de passer plus de 5 minutes sur le navigateur ^^

git stocke pas de diff? Ca sort d'ou cette info?

il fait ca pour les binaires oui mais des qu'il peut il fait de l'incrémental...

Godzil (./2123) :
- tu fais des changements dans le fichier qui induisent en plus des changements dans les white spaces ignorer les différences de white space lors d'un diff/blame est ce que tu veux, ça ne changera pas la façon dont git sauvegarde le fichier en interne, il garde le fichier entier et pas juste un diff avec la version précédente.

Oui mais il te permet de visualiser, entres autres, le dernier auteur de chaque ligne et ça ne semble avoir aucun rapport avec la façon dont le diff est calculé. Encore une fois si tu sais changer ça, j'aimerais voir la configuration parce qu'à ma connaissance ça n'est pas possible.

./2124 > Ah ben #JetBrains# quoi ^^

Squally: subversion et cvs fonctionnant avec les diff, pas git.
git stocke les fichiers entier, c'est ce qui lui permet de travailler aussi rapidement,et de pas passer 3heures à résoudre depuis la révision originale la liste de diff pour obtenir le fichier que tu veux.

wikipedia:
https://en.wikipedia.org/wiki/Git

Git stores each revision of a file as a unique blob. The relationships between the blobs can be found through examining the tree and commit objects. Newly added objects are stored in their entirety using zlib compression. This can consume a large amount of disk space quickly, so objects can be combined into packs, which use delta compression to save space, storing blobs as their changes relative to other blobs
.

c'est en effet pas systématique si tu travailles en local mais dès que tu bosses en remote tout passe par des packs, et la c'est svn like.

Les packs oui, mais les packs sont la pour du stockage et non travailler sur l'historique, d’où la compression et le stockage sous forme de diff.

Le fichier est de toute maniere stoque au moins une fois en entier dans un pack, peux etre deux avec sa version en "sortie" du pack. Mais ce n'est clairement pas le format par défaut, et si on dépack on se retrouve avec une copie de chacun des fichiers, ce qui est bien avec git c'est qu'il ne stocke pas un fichier sous son nom, mais sous son hash, donc si plusieurs fichiers on le meme hash, il ne sont stocke qu'une seule fois.

Bref, le pack n'est pas la forme de travail de toute maniere.


Sinon
https://git-scm.com/docs/git-blame :

-w Ignore whitespace when comparing the parent’s version and the child’s to find where the lines came from.

http://stackoverflow.com/questions/7310033/how-to-make-git-diff-ignore-space-change-the-default

ou:

http://unix.stackexchange.com/questions/10277/ignore-whitespaces-changes-in-all-git-commands

Je ne suis toujours pas sur de quel est ton probleme Zeph avec les whitespaces :/