renesisx wrote:
Otis wrote:
Yes, though I'd not use such a thing on .NET. Don't get me wrong, you should use what you want to use, but in general, it's best to adapt the naming schemes used the most on the target platform. Which thus means camel cased method/property/field names in java and Pascal cased method/property/field names in .NET. Sooner or later you'll regret it.
Oh, I'm with you. The problem I have is that you guys have known about this limitation in LLBLGen for a long time and have conciously chosen to force your ideology onto your customers. You're making presumptions about how your users will want to use your product.
Well, why would we spend time on a feature no-one would use (ok, a small group ) ? We also don't offer the option to generate code in hungarian coding style for example.
I didn't design this customer's database or existing code, but I do need to work to their style, and the lack of a simple checkbox to keep the field names identical to the DB field names (where possible) is a big limitation.
No it's not, as it's very rare that someone would want to use camelcased field/property names. And if s/he wants to, a plugin is a 'solution' to that rare circumstance. Though you have to run it every time, but it's your choice to opt for a rare naming scheme.
Added to that: MS gives our their .NET code with solely pascal cased methods and properties.
What I do in private with my code is my choice. You can advise me that I'm making a bad decision - feel free to bring up a big red flashing warning box when I choose a path you disagree with, but still give me the freedom to make that decision. That is all I ask.
If you want to, you can write a small plugin which traverses the fields etc. But we can't nor will add features for every naming scheme on the planet, as that's simply undoable. We chose to commit to the MS guidelines, and that's what we'll keep on doing.
The two options aren't effecting the first character of the name, which is always uppercased.