Riempire array

[k.b]

Virus non esageriamo, mi sembra che tu voglia far passare per verita' assolute alcune tue idee totalmente personali.

Ad esempio (esulando dal caso specifico), dove sta scritto che for non va bene per un ciclo infinito e while si? In entrambi i casi se non interrompi il ciclo finirai in un loop infinito.

E cos'hanno di male le proprieta' il cui nome inizia con un underscore? IMHO e' una convenzione come un'altra, spesso questa notazione viene indicata per metodi e proprieta' privati e non ci vedo niente di male, anzi e' una convenzione che uso spesso. Il fatto che tu faccia fatica a premere shift non la rende una bad practice

Il camel case pure e' una tua preferenza, non e' certo l'unica notazione valida per il naming delle variabili (ad esempio a me non piace).

Insomma prima di pontificare con questi toni, impara a distinguere le best practices generalmente accettate dalla community (e motivate su basi solide) dalle tue preferenze personali.

[Virus_101]

Originariamente inviato da k.b
Virus non esageriamo, mi sembra che tu voglia far passare per verita' assolute alcune tue idee totalmente personali.

Non dico che sono verità assolute ma approcci migliori che danno subito visiblità e comprensione del codice anche ad una lettura veloce, troppe volte mi sono trovato a riprendere in mano codice vecchio e a perdere un sacco di tempo per capire le cassate che avevo fatto, solo perche' avevo usato strutture, nomi e costrutti non facilmente leggibili.

Certo sono idee personali, che derivano da molti errori fatti in passato, quindi scrivere bene il codice non vuol dire solo farlo sintatticamente corretto, ma anche strutturalmente e semanticamente, in modo che sia facile cosa cosa si sta facendo in quel pezzo di codice.

Originariamente inviato da k.b
Ad esempio (esulando dal caso specifico), dove sta scritto che for non va bene per un ciclo infinito e while si? In entrambi i casi se non interrompi il ciclo finirai in un loop infinito.

No fermo 1 secondo, nessuno dice che non puoi farlo, vuoi usare for piuttosto di while o di foreach etc... ok sintatticamente la soluzione e' corretta e algoritmicamente e' equivalente (se imposti correttamente i limiti), dico solo che nel caso di dover affrontare dei cicli indefiniti su set di dati o istruzioni di cui si ignorano a priori le dimensioni, indici o numero di loop da fare, conviene sempre usare il while, che se nn erro da definizione e' dichiaratamente l'istruzione da usare per i cicli indefiniti.

For d'altro canto e' usato per cicili ben definiti, questo deriva dalla mia esperienza in c, dove bisognava davvero stare molto attenti a queste cose onde evitare seg. faults, che impallavano tutto a differenze di java o linguaggi con livello di astrazione piu' elevato dove puoi gestire le eccezioni o gli errori runtime.

Il mio discorso e' molto tranquillo qui, e verte sul fatto di applicare il corretto costrutto alla situazione in analisi, quindi certo posso usare for, while foreach , do while etc.... indistintamente l'uno dall'altro basta che alla fine siano equivalenti, ma per semplificarsi la vita e avere del codice che possa avere il maggior grado di comprensibilità anche dopo tanto tempo che non lo si tocca, o se lo deve usare altra persona.

Originariamente inviato da k.b
E cos'hanno di male le proprieta' il cui nome inizia con un underscore? IMHO e' una convenzione come un'altra, spesso questa notazione viene indicata per metodi e proprieta' privati e non ci vedo niente di male, anzi e' una convenzione che uso spesso. Il fatto che tu faccia fatica a premere shift non la rende una bad practice

ok capisco, sono preferenze personali certo, posso inoltre dipendere dagli standards definiti dal progetto ok succede a volde di dover litigar con ste cose. Cmq io resto dell'idea che oltre alla difficoltà di digitazione per quanto riguarda $this->_campo , io preferisco evitare di usare gli unserscore prima del nome var viste le numerose var di php e funzioni stesse di php che ne fanno uso. Vuoi identificare le private dalle pubbliche $pvt_miaVariabilePrivata , $pub_miaVariabilePubblica , anche qui CHIUNQUE legga queste var capisce cosa sono, e se metti le mani sul codice dopo 3 anni sai subito che cosa sono, altrimenti devi perdere tempo.
Quindi per me e' una best practice lasciare che le var tipo $_[quellochesia] siano var di php e le mie le definisco in maniera piu' verbosa, per aver maggiore leggibilità, non sai le saracche che partono quando mi trovo vechcio codice con variabili tipo $cp , $bl , $fr o $_cdl etc. etc.
non si capisce cosa sono ne cosa fanno e si perde un sacco di tempo.

Originariamente inviato da k.b
Il camel case pure e' una tua preferenza, non e' certo l'unica notazione valida per il naming delle variabili (ad esempio a me non piace).

Si vero ce ne sono molte altre di notazioni, mi spiace che non ti piace e' una notazione molto comoda e molto usata. CMq ce ne sono un sacco di altre(vedasi anche quella "ungherese" citata sopra )

Originariamente inviato da k.b
Insomma prima di pontificare con questi toni, impara a distinguere le best practices generalmente accettate dalla community (e motivate su basi solide) dalle tue preferenze personali.

o.O
Secondo te usare un costrutto che da definizione serve per scopo x e lo applichi a situazione y e viceversa(vedasi cilci while/for) e' solo una mia pippa mentale ?
Consigliare di scrivere bene le variabili e esplicitare lo scoping di attributi/metodi e' una pippa mentale ?
Vabbe non commento .... lasciamo stare.

[ispuk]

Virus_11 si ti ringrazio per le precisazioni il mio era un approccio abbastanza ribelle :P

[k.b]

Originariamente inviato da Virus_101
Non dico che sono verità assolute ma approcci migliori che danno subito visiblità e comprensione del codice anche ad una lettura veloce, troppe volte mi sono trovato a riprendere in mano codice vecchio e a perdere un sacco di tempo per capire le cassate che avevo fatto, solo perche' avevo usato strutture, nomi e costrutti non facilmente leggibili.

Certo sono idee personali, che derivano da molti errori fatti in passato, quindi scrivere bene il codice non vuol dire solo farlo sintatticamente corretto, ma anche strutturalmente e semanticamente, in modo che sia facile cosa cosa si sta facendo in quel pezzo di codice.


No fermo 1 secondo, nessuno dice che non puoi farlo, vuoi usare for piuttosto di while o di foreach etc... ok sintatticamente la soluzione e' corretta e algoritmicamente e' equivalente (se imposti correttamente i limiti), dico solo che nel caso di dover affrontare dei cicli indefiniti su set di dati o istruzioni di cui si ignorano a priori le dimensioni, indici o numero di loop da fare, conviene sempre usare il while, che se nn erro da definizione e' dichiaratamente l'istruzione da usare per i cicli indefiniti.

Probabilmente avevo frainteso io pensando ai cicli infiniti come while ( TRUE ), per cui while o for non fa nessuna differenza.

Originariamente inviato da Virus_101
ok capisco, sono preferenze personali certo, posso inoltre dipendere dagli standards definiti dal progetto ok succede a volde di dover litigar con ste cose. Cmq io resto dell'idea che oltre alla difficoltà di digitazione per quanto riguarda $this->_campo , io preferisco evitare di usare gli unserscore prima del nome var viste le numerose var di php e funzioni stesse di php che ne fanno uso. Vuoi identificare le private dalle pubbliche $pvt_miaVariabilePrivata , $pub_miaVariabilePubblica , anche qui CHIUNQUE legga queste var capisce cosa sono, e se metti le mani sul codice dopo 3 anni sai subito che cosa sono, altrimenti devi perdere tempo.
Quindi per me e' una best practice lasciare che le var tipo $_[quellochesia] siano var di php e le mie le definisco in maniera piu' verbosa, per aver maggiore leggibilità, non sai le saracche che partono quando mi trovo vechcio codice con variabili tipo $cp , $bl , $fr o $_cdl etc. etc.
non si capisce cosa sono ne cosa fanno e si perde un sacco di tempo.

Qui si parlava di proprieta' di un oggetto, non di variabili globali, quindi il discorso e' molto diverso. Sulle variabili globali sono d'accordo, ma per quanto riguarda le proprieta' di un oggetto non c'e' possibilita' di conflitto con i vari globals, ti pare?

Io trovo che usare come convenzione l'underscore come carattere iniziali per proprieta' (e anche metodi) private o protected sia un'ottima cosa, e' una pratica molto usata e aiuta a distinguere immediatamente nel codice gli elementi pubblici da quelli riservati. Quindi in questo non sono d'accordo con il fatto che la tua avversione per l'underscore sia una best practice, anzi e' proprio il contrario.

Originariamente inviato da Virus_101
Consigliare di scrivere bene le variabili e esplicitare lo scoping di attributi/metodi e' una pippa mentale ?

Consigliare di scrivere bene le variabili e' un ottimo suggerimento, dare per scontato che come piace a te sia l'unico modo buono invece e' discutibile

[Virus_101]

Mi sono espresso male e di fretta erano le 2 e 40 di mattina .. e per questo chiedo scusa.
Avrei dovuto essere piu' chiaro e meno irruento(avevo appena finito di giocare la beta di guild wars 2 con botte da orbi.,... dovrei scegliere momenti meno adrenalinici per postare ) .


Avevo parlato di cicli indefiniti non infiniti li si ci siamo capiti male

Per il fatto che le prop di un oggetto non possno conflittare con le super globals si iamo daccordo visto lo scoping completamente differente delle due entità in questione.

Capisco che utilizzare l'underscore per le privare ma come dicevo sopra dovrebbe essere esplicitato lo scoping di tale entità, in questo caso preferisco la versione piu' verbosa della cosa

tipo appunto

private $pvt_innerField

alla versione

private $_innerField

Sintaticcamente non c'e' alcuna differenza, certo sematicamente invece si, ma non cambia cmq molto e sono sempre aprocci soggettivi.
Però dichiare il campo senza la relativa propietà no, li si dovrebbe sempre esplicitare altrimenti si richisa confusione.

class foo
{
     $_field
}

secondo me dovrebbe essere evitato come approccio e preferito uno dei seguenti

class camel
{
    private $pvt_myPrivateCamel;

}

// oppure 

class underscore
{
    private $_myUnderscroredAttr
}

Tutto qui, la best practice in questione era appunto relativa al discorso di scrivere ed esplicitare correttamente le variabili, i campi, le funzioni o metodi che siano. In modo da avere 1 standard leggibile anche per future modifiche ad opera anche di altri programmatori.

Poi ognuno di noi ha le sue scimmie, e scrive il codice secondo le proprie preferenze, quindi se posso definire da me gli standard da applicare ad 1 progetto di solito li definisco abb verbosi (almeno per il naming delle entità e quindi anche l'eventuale namespace dell'applicazione) in modo che se altri devono mettere le mani su quel codice possano capire cosa succedere indipendentemente dai commenti.

P.S.
per il discorso cclo infinito con for, i nuoni vecchi while($run) .... li ho usati solamente quando mi ero aprocciato alla programmazione di giochi, e alcune procedure in java dove non potevo sapere a priori quando fermare il ciclo ma solamente al verificarsi di determinate casistiche, e in ogni situazione non ho mai usato un for... nemmeno qui in quanto il while o do-while che fosse era decisamente piu' adatto. Ma queste sono solamente esperienze personali, dove ho applicato soluzioni determinate dalla necessità di risolvere un problema specifico.
In php finora (grazie a dio) non sono ancora incappato nella necessita di dover scrivere cicli del tipo while($run) anche perche' spesso in talo situazione preferisco usare ricorsione per analizare strutture di tipo alberale(vedasi xml di configurazione et affini) ...