Diciamo che devi scrivere del codice per correggere un bug che a prima vista da un altro ingegnere sembrerebbe strano o non necessario.
Sarebbe una buona o cattiva forma inserire il codice in un metodo chiamato ad esempio "avoidWindowFromJumpingWhenKeyboardAppears" o semplicemente chiamarlo "forceSpecifiedWindowPosition" e poi aggiungere un commento sul motivo per cui lo stai facendo quando chiami il metodo?
Penso che sia meglio dare un nome ai metodi basati su ciò che stai cercando di realizzare piuttosto che come, come parte dell'intera interfaccia pubblica / cosa di implementazione privata. Quindi, a parità di condizioni, la chiamerei "avoidWindowFromJumpingWhenKeyboardAppears".
Tuttavia, tutto il resto potrebbe non essere uguale. I parametri avranno senso in ugual misura con entrambi i nomi? Se devi passare la posizione della finestra a "forceSpecifiedWindowPosition" ha senso, ma non tanto per "avoidWindowFromJumpingWhenKeyboardAppears", che sembra non essere passato nulla o una finestra. Inoltre, se forzare la posizione della finestra potrebbe essere considerato un effetto collaterale (sembra un no - è l'effetto che vuoi) allora "avoidWindowFromJumpingWhenKeyboardAppears" avrebbe risultati che potrebbero essere inaspettati dal nome, quindi non lo chiamerei così.
supponendo che questo sia completamente inevitabile:
delle opzioni, userei preventWindowFromJumpingWhenKeyboardAppears ; specificando anche il problema nella documentazione del metodo (quali versioni è noto per apparire, come ripro, o un caso #).
Se stai introducendo qualcosa di imbarazzante, è meglio renderlo ovvio, dettagliare la motivazione / problema e mettere in quarantena la soluzione alternativa. altrimenti, le persone lo leggono e si confondono (o ne omettono l'uso se non hanno trascorso molto tempo con le interfacce). quindi potrebbero rimuoverlo in futuro perché non sono sicuri del perché esista ("... ma è stato testato correttamente sul sistema operativo più recente."). per casi veramente brutti, userò ancora più stigma sintattico perché il nome del metodo che hai scelto non risalta se sottoposto a scansione.
se puoi mantenerlo interamente all'interno dell'implementazione privata, ancora meglio.
infine, preventWindowFromJumpingWhenKeyboardAppears rende piuttosto ovvio sul sito di chiamata che esiste un bug legittimo e il contesto a cui appartiene, piuttosto che un'implementazione casuale. forceSpecifiedWindowPosition ha poco senso in confronto.
Non preoccuparti per l'orgoglio, tuo o di chiunque altro. Non preoccuparti per la buona forma. C'è solo una cosa di cui dovresti preoccuparti quando dai un nome a un metodo: Cosa si legge meglio nel codice chiamante?
Cosa vedrà qualcun altro, quando torneranno su questo codice in seguito? Vedranno un metodo che posiziona una finestra appena creata o vedranno qualcosa che sembra non fare nulla (quindi tentare di rimuoverla)?
Immagina te stesso come un futuro principiante che legge il metodo di chiamata. Non vuoi fare clic sull'implementazione del metodo per trovare nulla, né vuoi andare al controllo della versione o al bug tracking per scoprire perché è stato aggiunto qualcosa, stai solo provando a leggere il flusso di quel metodo.
Inserisci esattamente quante informazioni nel nome del metodo che vuoi leggere nel metodo di chiamata e non di più.
Tendo a pensare che i metodi di denominazione dovrebbero essere concisi e generali con i commenti che riempiono i dettagli specifici. Quindi penso che il tuo secondo nome sia migliore. Ma quello sono solo io.
Ecco alcune regole arbitrarie da seguire: