[topicalacon]Mort de rire dans le man.

\\Ouranos// · Le 02/07/2010, à 09:26

Sherwood51 a écrit :

La doc du Linux kernel style coding, dans l'intro:
Linux kernel coding style
This is a short document describing the preferred coding style for the
linux kernel. Coding style is very personal, and I won't _force_ my
views on anybody, but this is what goes for anything that I have to be
able to maintain, and I'd prefer it for most other things too. Please
at least consider the points made here.
First off, I'd suggest printing out a copy of the GNU coding standards,
and NOT read it. Burn them, it's a great symbolic gesture.

Et plus loin :

Now, some people will claim that having 8-character indentations makes
the code move too far to the right, and makes it hard to read on a
80-character terminal screen. The answer to that is that if you need
more than 3 levels of indentation, you're screwed anyway, and should fix
your program.
In short, 8-char indents make things easier to read, and have the added
benefit of warning you when you're nesting your functions too deep.
Heed that warning.

Pylades · Le 02/07/2010, à 09:43

Ouais, ça m’a fait drôle aussi, étant donné que j’ai souvent au moins cinq niveaux d’indentation. Ils doivent faire de toutes petites fonctions… Ce truc, c’est un peu similaire au style de codage d’Epitech, qui interdit les fonctions de plus de 25 lignes.

Dernière modification par Pylade (Le 02/07/2010, à 09:46)

Rolinh · Le 02/07/2010, à 20:01

Pylade a écrit :

(...) Ils doivent faire de toutes petites fonctions…

Ben l'idée c'est que des fonctions avec tout plein d'imbrications ça devient... incompréhensible!
Morceler son code en plusieurs petites fonctions est bien plus lisible et efficace quand on doit s'y replonger dedans. Mais j'avoue, les 80 colonnes avec un tab de 8 c'est chaud...

tshirtman · Le 02/07/2010, à 23:27

les gros niveaux d'imbrications sont aussi mauvais signes pour les perfs en général… la complexité d'une fonction étant fortement influencé par l'imbrication des boucles…

Pylades · Le 03/07/2010, à 00:32

Mouais, enfin avec plein de fonctions, tu perds des perfs parce que tu es sans arrêt train d’appeler. Avec des fonction de 30 à 50 lignes et de trois à six niveaux d’indentation, on reste dans le raisonnable, et on n’appelle pas une fonction toutes les trois instructions.

Enfin bon, un bon compilo avec certaines optimisations activées peut transformer une fonction en inline s’il le juge utile…

\\Ouranos// · Le 03/07/2010, à 00:33

Pylade a écrit :

Mouais, enfin avec plein de fonctions, tu perds des perfs parce que tu es sans arrêt train d’appeler. Avec des fonction de 30 à 50 lignes et de trois à six niveaux d’indentation, on reste dans le raisonnable, et on n’appelle pas une fonction toutes les trois instructions.
Enfin bon, un bon compilo avec certaines optimisations activées peut transformer une fonction en inline s’il le juge utile…

Mais tu fais des appels aux fonctions très souvent, même dans un programme standard. printf() et scanf() en sont deux exemples.

Link31 · Le 03/07/2010, à 01:48

\\Ouranos// a écrit :

Pylade a écrit :
Mouais, enfin avec plein de fonctions, tu perds des perfs parce que tu es sans arrêt train d’appeler. Avec des fonction de 30 à 50 lignes et de trois à six niveaux d’indentation, on reste dans le raisonnable, et on n’appelle pas une fonction toutes les trois instructions.
Enfin bon, un bon compilo avec certaines optimisations activées peut transformer une fonction en inline s’il le juge utile…
Mais tu fais des appels aux fonctions très souvent, même dans un programme standard. printf() et scanf() en sont deux exemples.

printf() et scanf(), en plus d'être des fonctions, utilisent des appels systèmes. Des appels systèmes d'entrée-sortie, en plus, ce qui signifie que ça requiert une commutation de contexte vers un autre processus (l'émulateur de terminal), tout en impliquant le driver graphique, etc. Il n'y a rien de pire au niveau des performances que des fonctions telles que printf() ou scanf(). Si tu fais des printf() trop rapidement, ton programme sera limité par la vitesse d'affichage

À côté de ça, appeler une fonction "interne", même très souvent, a un coût quasi-nul. Le fait qu'un bloc de code soit inline ou dans une fonction ne fait aucune différence, si le fonction est dans le même fichier et que le compilateur peut l'optimiser s'il le souhaite. Et même si elle est dans un autre fichier, ça ne changera pas grand chose, à moins de créer un encodeur vidéo...

Dernière modification par Link31 (Le 03/07/2010, à 01:49)

tshirtman · Le 03/07/2010, à 02:21

clair, les IO saylemal… si tu veux des perfs faut les limiter au maximum, et au pire, les désynchroniser de l'avancé du processus…

Pylades · Le 03/07/2010, à 02:21

\\Ouranos// a écrit :

Mais tu fais des appels aux fonctions très souvent, même dans un programme standard. printf() et scanf() en sont deux exemples.

Déjà, je n’utilise presque jamais printf et très peu scanf. Par exemple, sur les deux trucs que je code en ce moment, j’en ai un où les seuls appels externes sont malloc, free, et des appels à des fonctions de string.h (et je crois que pour ces dernières, gcc utilise des built-in à la place), et l’autre où j’ai juste un putchar et un getchar.

Et ensuite, je me suis mal exprimé, je voulais parler de fonctions de trois lignes…

Enfin bon, mon propos était de dire que si effectivement les grosses fonctions c’est un peu moche, il n’y a pas de raison de tomber dans l’extrême inverse.

\\Ouranos// · Le 04/07/2010, à 22:36

Slashdot a écrit :

You are not logged in. You can log in now, Create an Account, or post as Anonymous Coward.

:lol::lol:

Pylades · Le 21/07/2010, à 19:24

Ruby en vingt minutes a écrit :

Note : le traducteur a ici considéré qu’il était plus pertinent de conserver l’entièreté du code en anglais, plutôt que de présenter un mélange en « franglais » de mot-clés anglais et noms de variables français. L’usage d’un langage de programmation, quel qu’il soit, nécessite hélas (?) encore quelques notions essentielles dans la langue de Shakespeare.

Notez tout de même que je suis entièrement d’accord sur le fond, c’est ce genre de pratiques qui rendent les tutos traduits en français insupportables. Et ma traduction du K&R, en plus de comporter bien d’autres défauts, tombe dans cet excès de zèle.
Ça fait perdre toute sa beauté à l’ouvrage ; j’ai du mal à m’y plonger.

mydjey · Le 11/08/2010, à 03:53

apt-get sl

man sl

OPTIONS
       -a     An accident seems to happen. You'll feel pity for people who cry
              for help.

Dernière modification par mydjey (Le 11/08/2010, à 03:56)

Elzen · Le 11/08/2010, à 11:58

mydjey a écrit :

Pour sl, le mieux, c'est surtout la partie "BUGS", je trouve ^^

mydjey · Le 11/08/2010, à 13:35

ArkSeth a écrit :

Pour sl, le mieux, c'est surtout la partie "BUGS", je trouve ^^

J'ai pas compris l'humour de la partie BUGS.

Elzen · Le 11/08/2010, à 13:53

Bah, j'ai peut-être mal pigé le sens de la phrase, mais vu que sl est censé être destinée aux gens qui se gourrent en tapant ls, j'interprète ça comme « il y a un risque pour que de temps en temps, la commande fasse ce qu'on attendait d'elle »

Lumpy · Le 27/08/2010, à 13:05

$ tar -c -f - -C truc.tar
tar: Je refuse de créer un fichier d'archive vide (oui je suis lâche)

Il m'a fait bien rire celui_là, alors que j'essayais de modifier une commande étriquée !

tshirtman · Le 27/08/2010, à 16:13

ah ouais, énorme xD

Pylades · Le 27/08/2010, à 23:12

Il a dû revenir au moins trois au quatre fois dans la discussion, déjà.
C’est le plus connu…

Lumpy · Le 30/08/2010, à 11:45

C'est vrai, j'avais pas fait attention.

Pylades · Le 31/08/2010, à 19:05

Vu sur le site de Gnu :

<p>Application software developers should learn how to use the
accessibility features of the <acronym title="Integrated Development
Environment">IDE</acronym> or toolkit they employ to build their user
interface.  Programmers who need to implement access technology, or
work on a desktop or OS-level accessibility problem, will need to
understand the accessibility <acronym title="Application Programming
Interface">API</acronym>, and should choose the one that is compatible
with free OS/desktops.  These include the <a href="http://library.gnome.org/devel/accessibility-devel-guide/stable/index.html.en">GNOME accessibility API</a>
(GNU/Linux platforms only), the <a href="http://java.sun.com/javase/technologies/accessibility/docs/jaccess-1.3/doc/core-api.html">Java accessibility API</a> (GNU/Linux and
Windows) and <a href="http://www.linuxfoundation.org/collaborate/workgroups/accessibility/iaccessible2">iAccessible2</a> (GNU/Linux and Windows).</p>

Emacs…

Pour bien vous rendre compte de pourquoi c’est drôle, regardez ce que donnent ainsi les acronymes…
Bon, ceci est bien la preuve qu’il manque encore la fonction « éditeur de texte » à Emacs.

tshirtman · Le 07/09/2010, à 16:28

man primes a écrit :

BUGS
primes won’t get you a world record.

(package bsdgames)

LittleWhite · Le 26/09/2010, à 13:27

Il faut lire les exemples de doxygen ( installation Windows ... car sous Linux, je ne sais pas s'il y a )...
Voici celui que j'ai bien aimé (author.cpp):

/*! \class WindowsNT
 *  \brief Windows Nice Try.
 *  \author Bill Gates
 *  \author Several species of small furry animals gathered together 
 *          in a cave and grooving with a pict.
 *  \version 4.0
 *  \date    1996-1998
 *  \bug It crashes a lot and requires huge amounts of memory.
 *  \bug The class introduces the more bugs, the longer it is used.
 *  \warning This class may explode in your face.
 *  \warning If you inherit anything from this class, you're doomed.
 */

class WindowsNT {};

LittleWhite · Le 10/10/2010, à 15:12

Ok, ce n'est pas dans un man mais bon:

http://www.gnu.org/fun/fun.html

NLS le pingouin · Le 28/10/2010, à 22:51

Un nouveau coup avec ALICE :

Human: Do you have any easter egg
ALICE: No I don't think I have any easter egg. But I do have a lot of friends on the web.
Human: Who?
ALICE: Bill Gates. :-).

Jules Petibidon · Le 04/11/2010, à 16:50

Une RFC sympa pour les membres du tdcct (ou du tdct, ou le tctdchépakoi, bref, les couche tard)

http://tools.ietf.org/html/rfc2324

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#176 Le 02/07/2010, à 09:26

Re : [topicalacon]Mort de rire dans le man.

#177 Le 02/07/2010, à 09:43

Re : [topicalacon]Mort de rire dans le man.

#178 Le 02/07/2010, à 20:01

Re : [topicalacon]Mort de rire dans le man.

#179 Le 02/07/2010, à 23:27

Re : [topicalacon]Mort de rire dans le man.

#180 Le 03/07/2010, à 00:32

Re : [topicalacon]Mort de rire dans le man.

#181 Le 03/07/2010, à 00:33

Re : [topicalacon]Mort de rire dans le man.

#182 Le 03/07/2010, à 01:48

Re : [topicalacon]Mort de rire dans le man.

#183 Le 03/07/2010, à 02:21

Re : [topicalacon]Mort de rire dans le man.

#184 Le 03/07/2010, à 02:21

Re : [topicalacon]Mort de rire dans le man.

#185 Le 04/07/2010, à 22:36

Re : [topicalacon]Mort de rire dans le man.

#186 Le 21/07/2010, à 19:24

Re : [topicalacon]Mort de rire dans le man.

#187 Le 11/08/2010, à 03:53

Re : [topicalacon]Mort de rire dans le man.

#188 Le 11/08/2010, à 11:58

Re : [topicalacon]Mort de rire dans le man.

#189 Le 11/08/2010, à 13:35

Re : [topicalacon]Mort de rire dans le man.

#190 Le 11/08/2010, à 13:53

Re : [topicalacon]Mort de rire dans le man.

#191 Le 27/08/2010, à 13:05

Re : [topicalacon]Mort de rire dans le man.

#192 Le 27/08/2010, à 16:13

Re : [topicalacon]Mort de rire dans le man.

#193 Le 27/08/2010, à 23:12

Re : [topicalacon]Mort de rire dans le man.

#194 Le 30/08/2010, à 11:45

Re : [topicalacon]Mort de rire dans le man.

#195 Le 31/08/2010, à 19:05

Re : [topicalacon]Mort de rire dans le man.

#196 Le 07/09/2010, à 16:28

Re : [topicalacon]Mort de rire dans le man.

#197 Le 26/09/2010, à 13:27

Re : [topicalacon]Mort de rire dans le man.

#198 Le 10/10/2010, à 15:12

Re : [topicalacon]Mort de rire dans le man.

#199 Le 28/10/2010, à 22:51

Re : [topicalacon]Mort de rire dans le man.

#200 Le 04/11/2010, à 16:50

Re : [topicalacon]Mort de rire dans le man.

Pied de page des forums