Ich glaube ich habe nie gesagt das Methoden da besser sind als funktionen weils neuer ist. Wenn ich mich richtig entsinne habe ich das über einen relativ ausführlichen Text diskutiert und mit Beispielen unterlegt
Aber wenn du schon val anbringst, lass mich erklären warum das so eine echt schlechte variante ist. Und nein, das hat nichts mit alter zu tun, wenn mir heute jemand code wie Val in eine Codebase committen wöllte, würde ich den merge request ablehnen egal wie neu der code ist.
Das größte problem mit Val ist der name. Val wird in den allermeisten Fällen genauso verwendet wie TryStrToInt, wie in deinem beispiel gezeigt.
Vergleicht man jetzt nur vom Namen Val und TryStrToInt, so ist ziemlich klar was die TryStrToInt macht, es versucht einen string in einen integer zu konvertieren. Es ist sogar so klar, das man, wie z.b. ich früher, die funktion ganz von selbst entdecken kann (dank autocomplete) und nur durch den Namen und signatur weiss was die funktion macht. Ich konnte die funktion finden und benutzen ohne die dokumentation zu brauchen. Das ist gutes Design und eine eigenschaft die man so viel wie möglich haben will.
Val auf der anderen seite hat einen komplett generischen namen. Es wurde sogar darauf verzichtet den begriff value auszuschreiben. So viel Zeit sollte wohl sein die paar extra Buchstaben zu tippen, vor allem mit modernen IDEs die über intelligente autovervollständigung einem das tippen von Namen sowieso zum großteil abnehmen können. Wir können es uns leisten funktionen bedeutungsvolle namen zu geben. Keine deadline wird verletzt weil die programmierer mehr als 3 buchstaben für funktionsnamen tippen müssen.
Während ich TryIntToStr selbst entdeckt und ohne jedwede dokumentation verstanden habe, erinnere ich mich das als ich das erste mal Val in code gesehen habe ich erst mal nachschauen musste was die funktion eigentlich macht.
Allein das disqualifiziert val schon einmal gegenüber TryStrToInt. Für code wie dein Beispiel gibt es keinen grund val über TryStrToInt zu bevorzugen.
Dann, abgesehen von dem herzlichst bescheidenen namen, ist Val aus einem mir unerfindlichen grund eine prozedur die ausgabe als parameter gibt. Es gibt bereits ein konzept für codeblöcke die ergebnisse zurückgeben sollen, das nennt sich Funktion mit return value.
Zum Vergleich nehmen wir mal wieder TryStrToInt, was eine funktion ist:
Dein code braucht 2 zeilen und eine zusätzliche variable, du brauchst also mehr code (mehr im sinne von Strukturen nicht unbedingt zeichen, auch wenn du da auch mehr hast) um die gleiche Information darzustellen. Wenn es um code Qualität und komplexität geht borgt man sich gerne den begriff der signal to noise Ratio (SNR) aus der Informationstheorie, also wie viel Information (signal) is dort im verhältnis zu sachen drum herum (die noise) wie z.b. boilerplate code. Je mehr code du also brauchst um die selbe menege an information zu vermitteln desto schlechter die SNR und damit desto schwerer ist der code zu verstehen. Und was das angeht ist Val deutlich komplexer als TryStrToInt bei der gleichen Information die der code darstellt (also: converte string on int und check obs funktioniert hat)
So herzlichen glückwunsch, du hast es wirklich geschafft das wohl schlechtest mögliche Beispiel zu finden. Es gibt viele gute gründe einen expliziten error check in die conversion einzubauen, es gibt keinen einzigen guten grund aber Val statt TryStrToInt zu verwenden
PS: ich gehe davon aus das die variablen Namen s und i nur als Beispiel sind, in produktiv code sollten variablen (ausser eventuell loop variablen) natürlich auch vernünftige namen bekommem, hier gilt das gleiche was ich oben zu Val geschrieben habe