Double post...
En prime, condenser comme tu le fais peut avoir des problème, puisque tu ne contrôles plus réellement le retour, tu laisses celui-ci aux fonctions que tu utilises.
Dépendant des cas, quand les retours peuvent être différent selon les plates-formes ou les compilateurs (soyons fou), cela peut poser de gros soucis.

Pour cette raison, des tests unitaires pourraient t'aider dans ces genres de cas.

Ok merci pour tes conseils ! Il faudra que je me renseigne sur les tests unitaires car comme ça, ça ne me dit rien.

Par contre dans ta fonction au dessus, quand tu fais ça :

for(x; x >=0; x--)
{
free(mapData[x]);
mapData[x] = NULL;
}

Tu risques d'avoir un soucis non ? Car si il y a eu une erreur d'allocation, l'utilisation de free ne doit pas se faire. Ou alors ça ne pose pas de problème ?

ne doit pas se faire sur l'endroit non alloué*

Désolée du triple poste, je viens de me renseigner, je ne savais pas que l'on pouvait tout à fait utiliser free sur un pointeur NULL.

Du coup c'est vrai que c'est vachement plus pratique à la relecture

Euh... Joker ^^'
Tu m'apprends toi-même quelque chose. Comme dit, cela fait 3 an que je n'ai pas fait de C, et c'était à un niveau scolaire assez faible dirai-je. Le cas présenté ne m'a pas du tout traversé l'esprit.

Pour ma part si une fonction ne peut pas tenir sur un seul écran au niveau lisibilité, y a un problème de conception.... et surtout ça ne rend service à personne d'avoir des fonctions de 3km partout...

De mon coté aussi, mais je suis conscient que, dans de rares cas, ce n'est malheureusement pas possible.

Très rares alors. En tout cas il ne m'a jamais été impossible de refactorer du code ou factoriser du code. Si vraiment ton code est trop long, découpe le en fonctions... que tu appelles l'une après l'autre avec des paramètres. ça sert à ça aussi

Merci grand manitou de m'apprendre l'utilité des fonctions et méthodes. Moi qui me contentais de tout mettre dans mon main à la suite, je vois à présent la lumière percer les nuages et m'ouvrir les yeux sur un monde rempli de licornes bigarrées.

Je ne me base pas sur mon expérience, qui n'est en rien significative, n'étant pas omniscient.
Je n'ai jamais rencontré ce cas, et enjoignant de toutes mes forces mes collègues à respecter les principes de responsabilités et de concision (en faisant attention à la lisibilité et la compréhension), je pense être à jour de ce coté-là.
Je me base simplement sur divers retours de développeurs senior que j'ai lu, et je préfère ne pas les mettre de coté juste parce que je n'ai pas rencontré cette situation moi-même.

dans ce cas trouve moi un exemple concret

Vu que je n'en ai jamais rencontré et que je n'en imagine pas... ça va être compliqué... Je l'envisage simplement. Pour sourcer, je suis bien en peine là aussi, ne classifiant pas chaque article et retour que je constate pour les ressortir au détour d'un débat.

Pourquoi es-tu gêné par l'existence de cette très mince probabilité au point que tu veuilles impérativement la détruire ?

je ne remets pas en cause ce que tu dis hein, mais bon j'ai vu tant d'ouvrages de programmeurs expérimentés qui ont une carrière bien plus longue que ma vie et qui ont toujours pointé en mal ce genre de choses et préconisé le refactoring plutôt que de croire qu'on ne pouvait rien faire. Ce qu'on peut faire (pisser du code énorme) on peut le défaire

Voui, je suis aussi d'accord avec ça (ce que je dis depuis le début , juste que j'estime plausible des cas particuliers rendant la chose impossible.
M'est avis que c'est normalement possible si l'on s'en donne les moyens... mais bon, pour avoir lu pas mal d'anecdotes sur thedailywtf que je n'aurai pas pu imaginer tellement les situations étaient ubuesques (je pense notamment à un article ayant deux filesystems sur la même machine et utilisant des techniques ésotériques pour communiquer), je ne peux simplement pas m'empêcher de penser que la situation puisse exister.

Malheureusement, les bonnes pratiques et la logique simple semblent parfois être intégralement absentes...

Silvermo -> En systèmes embarqués on va préférer minimiser l'utilisation de fonctions pour plusieurs raisons:
- Utilisation d'espace mémoire data sur la stack due au passage des arguments.
- Utilisation d'espace mémoire programme due au code nécessaire à la sauvegarde/restauration des registres
- Ralentissement encouru qui peut parfois être significatif dans le cadre de routines temps-réel.

Cependant, il y a éventuellement moyen de séparer le code pour la lisibilité et de demander au compilateur de l'inliner. Il faut cependant un compilateur suffisamment flexible (pas toujours le cas en embarqué), être conscient qu'on introduit une dépendance du code par rapport au compilateur, et devoir accepter la présence de nombreux #pragma ou __attribute__ qui peuvent également nuire à la compréhension.

Il y a donc effectivement des cas où on va préférer éviter, quand c'est bien réfléchi. Cela étant dit, il y a tout autant d'arguments à conserver une bonne compartimentation lorsque cela est possible dans le domaine. Je pense essentiellement à la complexité des tests unitaires ou formels, et de façon générale à la réduction des risques d'erreur. Dans le domaine, entre-autres (fortement au pluriel), j'ai par exemple rencontré les règles de codage suivantes:
- Complexité cyclomatique <= 10
- Imbrication du code <= 6
- Fonction de 100 lignes (C) maximum

elite_2009 -> Et encore, ça c'est juste pour préparer les caractères. Pour les afficher sur la console, faut encore faire un sycall.

Si tu es curieux, dans Linux (du moins 3.2.35, sources que j'ai sous la main), le syscall atterrit à fs/read_write.c:477.

Et ben bordel... faudrait que je vois autre chose que du développement Android moi. Pour le coup, ma vision est trop java-centrée de ce que je vois. Merci

Mjonir : ok mais dans ce cas tu me dis que ce sont des limite surtout des contraintes techniques qui provoquent ce genre de problèmes et non pas des soucis de conception du développeur

Tout à fait. Sémantiquement il n'y a jamais rien qui va t'empêcher de séparer une partie de code dans une fonction. Après, celle-ci peut être un peu pénible à écrire (surtout au niveau du retour), pas forcément bien placée, demander beaucoup d'arguments... mais c'est toujours possible. Et puis c'est quand même pour ce genre de choses que les compilateurs existent :p

Personnellement je pense qu'ultimement la performance doit passer avant la lisibilité, et si il faut produire du code illisible pour gagner en performance alors il faut le faire.

Après tout l'utilisateur du produit fini appréciera toujours le gain de performance, que ce soit pour un OS, un jeu vidéo ou un logiciel quelconque, en revanche il s'en tape royalement de savoir si le code est lisible.

Mais penses tu vraiment que cela peut couter tant que ça en performances de factoriser un minimum le code ? avec les technologies d'aujourd'hui...