Tach!
Ich mag eigentlich eigensichere Programmierung, wenn es möglich ist. Die Funktionen überprüfen ihre Argumente, sanieren sie, wenn sinnvoll oder brechen ab, wenn Fehler oder Fehlanzeigen vorhanden sind.
Dazu gehört auch, dass Werte solange im Urzustand erhalten bleiben, bis sie benötigt werden. Man weiß ja nie, mit welchen Funktionen/Methoden man sonst noch darauf zugreifen muss.
Ich weiß ja nicht, wozu du den Eingabewert als String noch benötigst, aber auch dann sollte die API einer Funktion klar definiert sein und nicht als "übergib mir einfach irgendwas, ich korrigiere mir das so zu recht, wie ich denke, dass es richtig ist".
Wenn es unbedingt eine Sicherung sein soll, teste auf Number ungleich NaN oder ähnliches und brich ab, statt zu mutmaßen, dass parseInt() die richtige Funktion ist, um den Eingaberwert zu korrigieren. Das wäre auch eher Eigenmächtigkeit statt Eigensicherung. So wie das jetzt ist, sichert das jedenfalls nur zahlenähnliche Eingaben. Alles andere ergibt NaN und macht das Arbeiten im Inneren der Funktion ineffektiv. (Nebenbei: effektiv und effizient sind keine Synonyme.)
Wenn du darauf bestehst, einen String bis an die Funktion führen zu wollen, dann schreib das parseInt() lieber in die Parameterübergabe beim Aufruf der Funktion.
Aber das ist meine persönliche Philosphie.
Die Anzahl der Vorkommen sollte eine Zahl sein. Und wenn dazu eine Hilfsvariable angelegt werden muss, um deiner Philosophie gerecht zu werden. Alternativ kann der Wert erneut aus dem Eingabefeld abgefragt werden, wenn er unbedingt im Original inklusive aller Eingabefehler benötigt wird.
dedlfix.