Je me posais une question
 
Imaginons qu'on ai un tres gros StringBuffer  
 
Est ce qu'il vaut mieux modifier le StringBuffer à l'aide d'une méthode void et modifier le parametre passer en référence

 
ou bien en passant par un return

Aux dernières nouvelles BufferedWriter#write renvoie void, donc le 3e bloc de code ne veut rien dire. Au final il n'y a pas de différence, mais il faudrait plus de code pour savoir quel est le but de ta fonction d'écriture.

okay mauvais exemple
 
prenons l exemple d'un StringBuffer

Je te conseille fortement de prendre la 1ere solution car si ta fonction retourne toujours le paramètre, ça ne sert à rien.
 
De plus imaginons 3 appels consécutif à la même méthode :
 
Version pas de retour :  

 
Version 1 avec retour :

 
Version 2 avec retour :

 
...

Je me posais cette question c'est parce que j'ai toujours eu l'habitude faire des return même si techniquement c'est inutile
je trouve cela plus pratique car imaginons une méthode qu'on découvre (on ne connait pas son comportement) comme celle ci
 

 
Si je me retrouve dans le cas machin1, je suis quand même obliger de dérouler le code jusqu'à la fin pour savoir si je ne renter pas dans un cas tordu
 

 
la je peux d'un coup d'oeil voir que le if s'arrête sur le return
 
Et donc je voulais votre avis
Et au niveau mémoire, corrigez moi si je me trompe mais cela ne prends pas plus de mémoire en passant par les returns (pointeurs sur le même objet , donc pas plus de mémoire toussa ...)

non non

De toute façon si tu n'as que des "else if" tu es sûr de ne pas avoir de surprise

oui c'est vrai qu en y réfléchissant plus , c'etait une mauvaise habitude de ma part de toujours utiliser des return
 
merci Bidem d'avoir éclairci une zone d'ombre

Dans ces cas-là,il est bon de se poser la question de savoir si on peut retourner une info utile plutôt que void, parce que trois fois sur quatre, cette info va être demandée par l'appelant. Donc se demander comment la fonction va être utilisée.

Par ex ici, je retournerais bien la longeur finale de sb.
Ca permet à l'appelant de faire en une ligne:
if (ajouter(sb) > 0){
   ...
}
else {
  ... //erreur : la chaîne est vide !
}

(bon, ici, l'exemple est mal choisi car la longueur est forcément > 0, mais si la fonction ajouter prenait deux paramètres: buf et une chaine supplémentaire à ajouter, la longueur finale serait une donnée certainement utile.)

question de sémantique et de clarté de ton api, mais dans le cas ou tu renvoie le SB, l'appelant peut se gourer et utiliser par la suite celui qu'il a passé a ta methode, qui n'est (dans aucun des deux cas, d'ailleurs) forcément le même.

le vrai cas vicieux c'est

... mais la au moins le seul qui se fait casser la gueule c'est le con qui a écrit la methode.

edit: et alors, j'veux bien que tu te la pètes bilingue, mais tu vas me faire le plaisir d'écrire tes noms de méthode en anglais, hein. (ne fut-ce que pour éviter les

- sisi, déjà vu )

 
Alright , do not make useless "return" systematically and to force myself to name my objects in English