Pense-bête écoles d'informatique

L'idée est intéressante. Mais cela ressemble à un mix de pense-bête, de cours ultra simplifié, de catalogue de snippets.

Sur la forme : avec un article, tu n'auras jamais le concision nécessaire pour un pense-bête. Je préfère un reference card (cf par exemple https://www.khronos.org/developers/reference-cards )

Sur le contenu :

• à mon avis, il faut séparer les différentes thématiques (tout le monde n'utilise pas vim, emacs ou git). En particulier ce qui est spécifique à 42 (qui n'est pas du tout une norme, loin de là. Et du coup renommer "norme" en "ce que l'on fait à 42 et qui est largement critiquable" ou "Norme à 42" en plus court)
• vire toutes les explications. Les explications vont dans un cours, si la personne ne connait pas une syntaxe vue dans un pense-bête, elle va voir un cours
• vire ce qui concerne la pratique. Par exemple "Taper une ancienne commande: Flèche du haut."
• librairie -> bibliothèque
• "Importer une librairie existante" -> include n'est pas une importation
• il manque un # dans ton define de macro
• taille des variables : non, cela peut changer en fonction du système
• opérations : besoin de rappeler que + permet de faire une addition, - une soustraction, etc. ? Que ++ peut s'écrire +1 ? Idem pour < <= > >= etc.
• "Fonction généralement interdite !" -> euh… non, c'est une fonction parfaitement autorisée (sauf à 42)
• pourquoi mettre && et pas les autres opérateurs logiques ?
• "Lire et créer une chaine de caractères avec While (tableaux)" -> ce n'est pas du pense-bête, c'est du snippet
• "Définition, déclaration et affectation d'un pointeur" -> les explications sont un peu bancale
• "La récursivité" -> snippet
• "L'allocation dynamique de mémoire" -> explications bancales
• indentation du code

Au final, j'ai l'impression de voir de notes de cours prise à l'école, ce qui est très utile pour toi, mais qui limite fortement la portée. A mon sens, pour faire un document qui a pour vocation d'être partagé, il faut se détacher de ce que tu as vu personnellement et avoir une vision plus générique : quelles sont les informations que l'on m'a pas donné et qui serait important d'ajouter ? quelles sont les informations que l'on m'a donné et qui sont spécifique de mon école ?

Concernant vim :

• vim se lance avec vim et pas Vim. Vim est très certainement un raccourci où tu es. Il y a aussi gvim qui offre une bien meilleure gestion du clavier – celle en console est assez déficiente.
• fn + F1 est probablement lié au manager de snippets qui est installé sur votre conf. Ce n'est pas standard.
• Le truc qui est important pour vim, c'est de comprendre qu'il y a une vingtaine de commandes d'un côté (yank, change, substitute, (select in) visual, =reindent, …), et autant de déplacements (double ou majuscule pour la ligne ça dépend -> yy, V, dd, S ; Majuscule ou dollar pour la fin de ligne -> y$, d$, C ; end-of-word ; word ; till-character -> dt( ; (et f qui fait la même chose, mais en incluant) ; plus tous les blocs motions -> inner-word, a-word, inner-", a-{ (-> =i{ pour réindenter le bloc d'accolades courant).
  Bref. Ainsi, il y a assez peu de choses à retenir et cela démultiplie les actions possibles.
• Concernant les mouvements avec hjkl, je n'ai jamais compris cet acharnement à imposer cette façon de faire. Les flèches du clavier marchent très bien, et bien mieux que hjkl en mode insertion.
• Tu as l'air d'être passé à côté de :make qui est un incontournable quand on utilise vim pour coder.

Concernant les règles de codage en vigueur chez vous.

• Interdire d'utiliser for est totalement crétin. Il n'y a rien de tel pour oublier l'instruction d'itération, surtout si le code de la boucle commence à un peu trop grossir (ce qui est certes une violation du SRP). Quitte à régir les boucles, je préfère la recommandation de Sean Parent (de chez Adobe) -> s'il doit y avoir une boucle dans une fonction, il ne doit y avoir rien d'autre, la fonction doit devenir un algorithme, et publiez-le à la communauté – et si par hasard il s'agit d'un algorithme qui existe déjà, vous auriez dû l'utiliser dès le début.
• Pour unifier tabs et espaces sous vim, c'est d'abord :set expandtab pour dire pas de tabs, puis :retab pour uniformiser le texte. gg=G c'est pour réindenter un code qui utilise d'autres conventions, ou qui est mal indenté.
• Boudiou. Quand on mélange volontairement tabs et espaces, on indente avec des tab, et on aligne avec des espaces. Mais bon, très peu d'outils permettent de travailler ainsi.

Comme le dit gbdivers, précise qu'il s'agit des règles en vigueur dans votre école 42. Elles sont loin de faire l'unanimité.

Le C:

• On dit library, libraries, ou bibliothèque, et pas librairie.
• sizeof(int) dépend des machines. Ce n'est pas nécessairement 4 octets.
• sizeof(char) est un byte. Et le nombre de bits d'un byte dépend de la machine – même s'il est rare que cela soit autre chose que 8 sur nos plateformes aujourd'hui – OK, là je pinaille à fond.
• A moins que vous soyez limité à des compilateurs C89 (les vieux VC++), déclarer les variables en début de bloc est une mauvaise pratique: http://cpp.developpez.com/faq/cpp/?page=Les-fonctions#Ou-dois-je-declarer-mes-variables-locales (et après ces couillons interdisent les for…)
• Pour les fichiers : toute opération sur des fichiers se teste (en particulier ouverture et lecture), l'oubli de ces tests implique souvent des heures de perdues à essayer de debugguer des programmes qui donnent des résultats bizarres.
• J'ai compris l'interdiction d'utilisation des VLA, mais c'est parce que je connais. L'explication de ce que c'est n'est pas claire (tableau type statique (en syntaxe de déclaration), mais dont l'argument de taille est une variable qui n'est pas une constante de compilation). NB: l'interdiction des VLA c'est soit en anticipation du cours de C++, soit parce que vous êtes vraiment sujet à utiliser des compilateurs C89 (ou du moins non entièrement compatibles avec le C99) (ce qui invaliderait ma remarque sur les déclarations retardées)

Bref, il y a pas mal de choses qui ne sont pas applicables en dehors de ton contexte.