Informatique

[08:43:48] <Bunyan>
Mais bon, j'suis plutôt partisan du "une méthode/fonction = un seul return" en règle général, et ça reste du choix personnel (en parti).

Tu connais des guidelines qui préconisent ça aussi ? Je sais que celle du C++ sont contre justement parce que ça complexifie les fonctions (le premier exemple le montre plutôt bien) : https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines.html#Rnr-single-return

Le 04 février 2021 à 00:47:46 ikigaimi a écrit :
pas nécessairement en fin de fonction, mais à certains endroits de la fonction (autant pour moi), comme dans ce code par exemple (lignes 55 et 65 de la version Java): https://www.techiedelight.com/quicksort-using-dutch-national-flag-algorithm/

Le 04 février 2021 à 00:47:46 ikigaimi a écrit :
pas nécessairement en fin de fonction, mais à certains endroits de la fonction (autant pour moi), comme dans ce code par exemple (lignes 55 et 65 de la version Java): https://www.techiedelight.com/quicksort-using-dutch-national-flag-algorithm/

Je le fais ça permet de sortir de la fonction si les paramètres en entrée sont incorrect, après suivant les cas vaut mieux lever une exception que faire un return, mais typiquement ce genre de cas est utile si tu as un traitement à faire sur un tableau, qu'au finale t'as aucun élément ou pas assez d'élément pour que ta fonction soit utile, tu as des paramètres vide ou null ... Ca t'évite que ta fonction s'exécute pour rien faire ou plante ...

Godrik qui me critiquait récemment pour mon apologie de l'assembleur, c'est justement dans ce genre de cas que générer le bytecode java ou l'assembleur C++ est utile pour bien comprendre ce genre truc.

Je vois difficilement en quoi montrer de l'assembleur faciliterait les explications

Le 04 février 2021 à 09:55:24 lokilok a écrit :

[08:43:48] <Bunyan>
Mais bon, j'suis plutôt partisan du "une méthode/fonction = un seul return" en règle général, et ça reste du choix personnel (en parti).

Tu connais des guidelines qui préconisent ça aussi ? Je sais que celle du C++ sont contre justement parce que ça complexifie les fonctions (le premier exemple le montre plutôt bien) : https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines.html#Rnr-single-return

Ca dépend du langage.

Typiquement en kotlin/scala, on peut réécrire le second cas à l'aide d'un pattern matching et bénéficier de syntaxe allégée, et pour le coup c'est bien plus propre:

fun main(args: Array<String>) {
    setOf(1, -2, 0)
    	.map { it.to(it.sign()) }
    	.forEach { (int, sign) -> println("$int is $sign") }
}

private fun Int.sign() = when {
  this < 0 -> "negative"
  this > 0 -> "positive"
  else -> "zero"
}

Le 04 février 2021 à 12:15:32 lokilok a écrit :
Je vois difficilement en quoi montrer de l'assembleur faciliterait les explications

Tu vois si le return dégage de la StackFrame

UnaryOperator, c'est pas tant le pattern matching qui rend ça possible, c'est plus le fait que if / else c'est uniquement un statement en C++ alors qu'en Kotlin ça peut être utilisé en tant qu'expression. Puis derrière t'as le pattern matching qui rend ça encore plus simple effectivement.

Mais oui c'est vrai certains langages facilitent le fait d'avoir un seul return, par contre je trouve le code de ton main pas très lisible, je crois que je commence à comprendre pourquoi godrik critique les API fonctionnelles style map/filter

ProTennix, mais pour que tes explications soient compréhensibles tu dois expliquer bien plus de choses que si tu décrivais simplement le fonctionnement de return du point de vue du langage de programmation. Je vois pas ce que ça simplifie.

Le 04 février 2021 à 12:04:52 ikigaimi a écrit :

Le 04 février 2021 à 02:29:54 godrik a écrit :
Dans ces cas la c'est pour terminer la fonction a ce point de l'execution. Quand la ligne 44 (ou 65) est executer, la fonction termine et l'execution retourne a la fonction appellante.

Ca arrive parfois que l'on mettent return; a la fin du corps d'une fonction. Ca ne sert a rien, c'est typiquement une convention stylistique.

l'execution retourne à la fonction appelante, c'est-à-dire qu'on sort de la fonction et on passe à la suite (les lignes suivantes) ? ou bien on revient en début de fonction (comme une fonction récursive)? Désolée

En C# (en java ça doit être la même chose), on sort de la fonction courante et on continue l'exécution sur la fonction appelante.

Le 04 février 2021 à 15:09:31 lokilok a écrit :

Mais oui c'est vrai certains langages facilitent le fait d'avoir un seul return, par contre je trouve le code de ton main pas très lisible, je crois que je commence à comprendre pourquoi godrik critique les API fonctionnelles style map/filter

Je vois pas comment on peut faire plus lisible que ça. Faut vivre avec son temps. Le paradigme fonctionnel (surtout en kotlin/scala) c'est monnaie courante

Le 04 février 2021 à 09:55:24 lokilok a écrit :

[08:43:48] <Bunyan>
Mais bon, j'suis plutôt partisan du "une méthode/fonction = un seul return" en règle général, et ça reste du choix personnel (en parti).

Tu connais des guidelines qui préconisent ça aussi ? Je sais que celle du C++ sont contre justement parce que ça complexifie les fonctions (le premier exemple le montre plutôt bien) : https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines.html#Rnr-single-return

Non, en general, ce sont des conventions propres a des projets en particulier. Avoir un seul return est en effet une convention stupide a mon avis. Un seul return c'est une convention qui vient de langages comme C qui n'a pas de destructeur implicite et deterministe. Et ou du fait avoir un seul return donne un point unique de desallocations des ressources. En C++, ce n'est pas utile. MISRA demande un seul return je pense (ou le demandais a un moment)

Mais j'ai vu des projets ou toutes les fonctions void finissent par return; a la fin de la fonction. C'est completement redondant, mais par convention toute les fonctions ont un return a la fin. Avant la } final. Ca sert a rien, mais c'est la.

Le 04 février 2021 à 16:04:06 UnaryOperator a écrit :

Le 04 février 2021 à 15:09:31 lokilok a écrit :

Mais oui c'est vrai certains langages facilitent le fait d'avoir un seul return, par contre je trouve le code de ton main pas très lisible, je crois que je commence à comprendre pourquoi godrik critique les API fonctionnelles style map/filter

Je vois pas comment on peut faire plus lisible que ça. Faut vivre avec son temps. Le paradigme fonctionnel (surtout en kotlin/scala) c'est monnaie courante

eye of the beholder tout ca.

Le 04 février 2021 à 12:04:52 ikigaimi a écrit :

Le 04 février 2021 à 02:29:54 godrik a écrit :
Dans ces cas la c'est pour terminer la fonction a ce point de l'execution. Quand la ligne 44 (ou 65) est executer, la fonction termine et l'execution retourne a la fonction appellante.

Ca arrive parfois que l'on mettent return; a la fin du corps d'une fonction. Ca ne sert a rien, c'est typiquement une convention stylistique.

l'execution retourne à la fonction appelante, c'est-à-dire qu'on sort de la fonction et on passe à la suite (les lignes suivantes) ? ou bien on revient en début de fonction (comme une fonction récursive)? Désolée

Mettons les fonctoins recursives de cote pour un moment. Regardes ce bout de code. (ici c'est du C++, mais java pareil)

#include <iostream>

void f(int x) {

  std::cout<<"ici"<<std::endl;
  if (x > 0) {
    std::cout<<"la"<<std::endl;
    return ;
  }
  std::cout<<"ailleurs"<<std::endl;
}


int main () {

  std::cout<<"avant"<<std::endl;
  f (1);
  std::cout<<"milieu"<<std::endl;
  f(-1);
  std::cout<<"apres"<<std::endl;

  return 0;
}

Ca donne ca:
avant ici la milieu ici ailleurs apres

Quand on a atteint le return;, l'execution de f a terminer et l'execution est retourne a la fonction qui a appeller f, ici c'est main. Donc l'execution de main continue.

Si f etait une fonction recursive, return te ferait sortir de l'execution courrant de f. Et peut etre que la fonction appellante est f, ou peut etre que c'est autre chose.

[16:04:06] <UnaryOperator>

Le 04 février 2021 à 15:09:31 lokilok a écrit :

Mais oui c'est vrai certains langages facilitent le fait d'avoir un seul return, par contre je trouve le code de ton main pas très lisible, je crois que je commence à comprendre pourquoi godrik critique les API fonctionnelles style map/filter

Je vois pas comment on peut faire plus lisible que ça. Faut vivre avec son temps. Le paradigme fonctionnel (surtout en kotlin/scala) c'est monnaie courante

Supposons que dans le print tu veux aussi afficher un paramètre "foo" qui serait le résultat de "bar(sign)", tu ferais comment ?

lokilok

Tu connais des guidelines qui préconisent ça aussi ? Je sais que celle du C++ sont contre justement parce que ça complexifie les fonctions (le premier exemple le montre plutôt bien) : https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines.html#Rnr-single-return

Le second me plaît plus à l'oeil à cause de mon habitude, mais je n'irai clairement pas faire un retour là-dessus si jamais c'était un code que je relisais. Il est trop simple, et j'évite d'être dogmatique en règle général

Pour moi, c'est surtout dans des cas plus complexe où je n'ai pas un "return" dans chaque branche du "if", avec des méthodes qui font plus de 40 lignes que je vais avoir un souci avec ça, car le flux de code est largement complexifié ("alors, la seconde branche du if fait un return, ainsi que sa cinquième, mais les autres vont jusqu'au bout...").
Ouaip, on pourrait dire que c'est une conséquence plus qu'un problème dans mon exemple (le problème étant que ça ait été codé n'importe comment), mais de mon avis, ça amplifie facilement les problèmes quand il n'y a pas de sérieuses relectures ni un sérieux (et sensé) découpage en fonction/méthode.

Ensuite, niveau guidelines en elles-mêmes, le "single entry, single exit" viendrait des très vieux langages, ainsi que du C [1], pour éviter des fuites mémoires et faciliter la gestion du flux de code à priori.
Hormis ça, c'est une guideline que j'ai fréquemment entendue dans l'écosystème Java.

[1] : https://softwareengineering.stackexchange.com/questions/118703/where-did-the-notion-of-one-return-only-come-from

Si vous voudriez commencer la programmation bas niveau, vous commencerez par C ou C++ ou Rust ?

J'ai des notions dans chacun de ces langages car j'ai bidouillé avec quelques fois, mais maintenant, à côté de mon apprentissage back end frotn end pour devenir Web dev, j'ai envie de me faire plaisir avec un langage assez bas niveau dans ce genre là. Autant pour apprendre que pour avoir dans mon bagage un langage véloce et qui me permettait de m'amuser à faire de petites librairies compatible pour Node ou deno.
Et j'avais un petit side project ou il me fallait un programme qui généré des fichiers etc, je comptais le faire en C# mais c'est l'occasion de le faire avec autre chose même si ça met plus de temps.

Vous prendriez quoi et pourquoi ?

Si c'est pour te faire plaisir, choisis celui qui te plaît le plus

D'un point de vu perso je choisirai Rust pour la découverte du langage ou C si je m'intéresse plus au projet qu'à l'apprentissage d'un langage.

Le 31 mars 2021 à 11:23:34 _S0uL a écrit :
Si c'est pour te faire plaisir, choisis celui qui te plaît le plus

D'un point de vu perso je choisirai Rust pour la découverte du langage ou C si je m'intéresse plus au projet qu'à l'apprentissage d'un langage.

D'accord. Oui bah le truc c'est qu'aucun me plaît d'avantage, mais Rust ressortait pas mal dans les threads que j'ai de ci de la sur Reddit, etc

J'imagine que Dev avec ça doit être vraiment cool.

Le 31 mars 2021 à 10:20:13 Feanor_ledev a écrit :
Si vous voudriez commencer la programmation bas niveau, vous commencerez par C ou C++ ou Rust ?

Si c'est pour faire de l'embarqué, C est le langage le plus supporté, donc le choix par excellence.

J'ai choisis le C++. Sur ce que je veux faire je peux faire ou du C ou du C++, j'imagine que c'est mieux de faire le C++ du coup.

J'ai un peu poussé vers le C, avant de voir que je pouvais bien faire du C++, la partie difficile du C c'est comprendre les pointeurs en général et le fait qu'il faut tout faire a la main. C'est pas évident mais c'est cool !

En tout cas c'est super sympa, et j'ai pas de difficulté a comprendre la syntaxe, les choses de bases comme ça. Comme quoi le C# et le JS/TS ça m'a pas mal aidé en fait.

En tout cas le C++ c'est vachement cool en fait, juste pour setup l'environnement c'est pas simple mais sinon après ca va tout seul pour commencer à bidouiller.

plusieurs forumeurs m'ont contacte recement aux sujet de topics qui disparaissent et des topics d'aide aux devoir. En parler ici semble raisonable donc allons y.

1/ On voit pas mal de topic de "j'ai un probleme, aidez moi" qui recoivent une reponse avec plein de details. Et un jour apres, OP efface le message et l'aide apporter par le forum disparait. Autant on ne peut pas empecher les forumeurs d'effacer leur topics, autant on peut essayer d'eduquer les forumeurs. Mais comment? Que pensez vous d'un topic epingle? Qu'est ce qu'il devrait dire?

2/ On voit aussi pas mal de topic de "faites mon TP", voir meme de "passez mon exam a ma place" qui me paraissent etre completement contre productif. Les cas les plus extreme sont supprimes par la moderation. Mais comment est ce que vous pensez qu'on devrait traiter la question?