Archief - [Java] Gebruik van this

Mocht ik zelf ooit kunnen beslissen over zulke conventie-regels kies ik natuurlijk ook voor de meest gebruikelijke, dat spreekt voor zich !

De William hadden we vooral in het eerste jaar. Hij komt beter en volwassener over dan andere assistenten (is ook ouder denk ik?) en hoort inderdaad bij de gerespecteerde assistenten.

Zeg hem dan dat de dades Kris Luyten en Carin Koninckx zijn! (En anderen onder hun)

kwitters zei:

Bullshit. Als je een hoop programmeurs vraagt om tesamen een code conventie op te stellen dan eindigd dat in heilige oorlogen. Ik heb dit al effectief gezien in een bedrijf, waarbij ze uiteindelijk toch besloten dat elke programmeur in zijn code vrij was om de conventie te gebruiken die hij/zei wou (was in C). Tegen de tijd dat je een conventie bent overeengekomen heb ik mijn Java applicatie al lang geschreven. Simpel, effectief, leesbaar voor iedereen, volgens de algemene conventie.

Klik om te vergroten...

Bwa, dat ging bij ons toch redelijk vlot hoor. Ik heb er een opgesteld, mij zo goed mogelijk aan de MS conventies gehouden met wat aanpassingen. (m_ ipv overal this. gaan gebruiken en andere kleine dingen die vaag gebaseerd zijn op die van iDesign trouwens.) Veel reactie is daar niet op gekomen dus tegen de tijd dat we moesten beginnen was het zo en niet anders.

Parnakra zei:

Wat je laatste zin betreft, er is an sich inderdaad niets mis aan m_ voor je membervariabelen te plaatsen, maar waarom zou je het doen? Als je enige reden 'omdat je dan kan zien dat het membervariabelen zijn' is, ga je beter een deftige IDE gaan gebruiken.

Klik om te vergroten...

In Visual Studio is er standaard geen onderscheid in kleur tussen member en gewone variabelen. Dat verschil zie je dus niet. Je kan dan overal this gaan voorzetten, maar persoonlijk vind ik dat niet echt de beste alternatieve oplossing. Dan liever m_ (of my_, our_, the_) dan _,$ of een ander gaar middel.

Tyfius zei:

In Visual Studio is er standaard geen onderscheid in kleur tussen member en gewone variabelen. Dat verschil zie je dus niet. Je kan dan overal this gaan voorzetten, maar persoonlijk vind ik dat niet echt de beste alternatieve oplossing. Dan liever m_ (of my_, our_, the_) dan _,$ of een ander gaar middel.

Klik om te vergroten...

Is het zo belangrijk dit onderscheid te zien? Ik ben in mijn code, of die van collega's nog nooit echt problemen gehad doordat er geen kleurverschil is tss memeber en gewone variabelen. Overal m_ beginnen voortypen, lijkt me ook wel een mengeling van stijlen (hungarian notation). Wat me redelijk overbodig lijkt gezien de hulp die je krijgt met intellisense. En het is ook niet bepaald de lijn volgen die microsoft gebruikt in .NET

Krueger zei:

Is het zo belangrijk dit onderscheid te zien? Ik ben in mijn code, of die van collega's nog nooit echt problemen gehad doordat er geen kleurverschil is tss memeber en gewone variabelen. Overal m_ beginnen voortypen, lijkt me ook wel een mengeling van stijlen (hungarian notation). Wat me redelijk overbodig lijkt gezien de hulp die je krijgt met intellisense. En het is ook niet bepaald de lijn volgen die microsoft gebruikt in .NET

Klik om te vergroten...

Dan moet je wel een duidelijke conventie aannemen over hoe je die noemt. Als ik een klasse Person maak die een firstname en lastname member variabele moeten hebben, dan kan ik in mijn constructor al niet dezelfde naam gebruiken terwijl dat de meest logische naam voor die variabele is. Meestal begin je dan af te korten of vrij zinloze namen te gebruiken. Dat is dan ook weer niet echt de bedoeling.

In elk programma zit wel eens een (te) lange functie die soms moeilijk op te splitsen is in verschillende functies. Dan vind ik het wel handig om meteen te zien wat member variabelen zijn en wat lokale variabelen zijn.

De lijn die MS gebruikt is trouwens overal this. voorzetten. Maar als je echt eens in hun code van het .NET framework gaat neuzen dan merk je daar ook al snel verschillende stijlen op hoor. Sommigen gebruiken _firstname, anderen ook m_firstname, anderen overal this. Zelf zijn ze dus ook niet echt consequent.