Hi Frans,

Do you consider in making generated code less verbose, or at least have an option to reduce verbosisty?

Here are few ideas:

• remove postfix Entity (CustomerEntity -> Customer)
• move Fields from [Name]Fields -> [Name] (i.e. CustomerEntity.Id instead of CustomerFields.Id) -> (Customer.Id)
• drop Entity from Relation names (i.e. OrderEntityUsingOrderId -> OrderUsingOrderId)

Code would be cleaner and it would still be readable (in the context of the use). I am sure there are other possibilites to code bloating..

mihies wrote:

Hi Frans,

Do you consider in making generated code less verbose, or at least have an option to reduce verbosisty?

Here are few ideas:

• remove postfix Entity (CustomerEntity -> Customer)
• move Fields from [Name]Fields -> [Name] (i.e. CustomerEntity.Id instead of CustomerFields.Id) -> (Customer.Id)
• drop Entity from Relation names (i.e. OrderEntityUsingOrderId -> OrderUsingOrderId)

Code would be cleaner and it would still be readable (in the context of the use). I am sure there are other possibilites to code bloating..

About Entity postfix: we tried to remove that from the code in v2.0, but it's not that easy. The thing is that it will lead to more compilation problems, as the risk of having a name clash with a type in the .NET framework is much higher. It's also a lot of work and it has to be optional as otherwise it will break code all over the place. So not a feature worth spending a lot of time on if there are other features waiting, IMHO

About the 'Fields' in CustomerFields: that's on purpose, as it's not possible to have a static property and a non-static property with the same name. (CustomerEntity.ID would imply that.). Sure, say we do add the option of dropping 'Entity' from the entity names, optionally, then it would be possible, though this would cause headaches in support, as the user then has to specify that the 'Entity' name was dropped, and that CustomerFields suddenly is called CustomerEntity. I don't think that's really that helpful. As code is out there already with these name elements, removing them isn't an option.

About removing 'Entity' from Relation names: It was added since the beginning, to be consistent. removing it should be optional as loads of code is already using the 'Entity' scheme.

With generated code, there's a problem: the names cooked up by the generator have to be unique, and also make sense. Sure, some people don't like 'Entity' but I don't consider it a big issue to spend a lot of time on, as it WILL need a lot of time, documentation and is likely to cause more problems than it would solve, as there's currently no problem with the name, other than 'it might not look great', however incompilable code, code differences between code generated on one machine versus code generated on another is IMHO a problem, which can occur with these optional features, and won't exist otherwise.

Understood and agreed to the certain level. Just to make one thing clear though: it is not that code looks bad, it is all about readibility which is very important when your construct involves more than a couple of tables and spawns across > 20 lines.

I use modified templates and regular expressions to do just what you are talking about here..

I leave the Fields descriptor on the end of field names but I remove Entity from all entity and relation names, so my code looks like:

EntityCollection<OrderDetail> orderDetails = _order.OrderDetails;

It is much more readable that way, especially when there is many entities involved but I do see where Frans is coming from, it would be a big headache trying to protect users from using reserved type names, etc..

I use modified templates and regular expressions to do just what you are talking about here..

I leave the Fields descriptor on the end of field names but I remove Entity from all entity and relation names, so my code looks like:

EntityCollection<OrderDetail> orderDetails = _order.OrderDetails;

Aha. The problem with this approach is that once new update is released you have to redo all the modifications which might be a pain because you have to compare how the original code changed etc.

It is much more readable that way, especially when there is many entities involved but I do see where Frans is coming from, it would be a big headache trying to protect users from using reserved type names, etc..

There aren't that much reserved type names afterall. And entities live in their namespace. If you compare LINQ to SQL with LLBLGenPro you'll see that the former code is much more readable (not counting LINQ) because it doesn't feature all the redundant postfixes. The bottom line is that I would be happy if there is a switch: "DontUsePrefixesAndRearrangeFieldsAndOtherStuffOnYourOwnRiskConsiderYourselfWarned" that would just eliminate stuff. If I put in a wrong name then compiler will let me know.

If I could start over, I might drop a suffix here and there, but dont forget that linq to sql has a limited scope in helping the user: if the user creates an entity 'Transaction' it will likely create incompilable code. For reasons like this, the suffix is there, simply because the user then doesn't have to worry about why the code doesn't compile; after all: generated code is supposed to be correct

a) I am not that sure. It might create problems due to ambiguity, however these problems are easily solved using namespaces.

b) So you would generate TransactionEntity class. But what if user has another TransactionEntity class defined somewhere? Can you prevent the ambiguity in this case?

I think that too much protection of user against himself/herself at the expense of other features (readability in this case) isn't doing that good. Instead user should understand at least the basics and thus user shouldn't do such stupid naming. And the compiled code should be correct as long as user is giving proper names to entities which is a reasonable tradeoff IMO.

For you it looks clear. For me too: no removal of the suffixes. We can't afford the ability that people have uncompilable generated code and have no clue why it doesn't compile. We already have that problem with VB.NET and entity fields which have the name of a class/type.

There are so many things to add/change already, the suffixes here and there is IMHO really a non-issue compared to those.

public <[If UsePartialClasses]>partial <[EndIf]>class <[CurrentEntityName]>Entity => public <[If UsePartialClasses]>partial <[EndIf]>class <[CurrentEntityName]><[EntitySuffix]>

This simple change (on all Entity hardcoded words) would solve the entire issue regarding Entity suffix and it would probably take less time than this thread. Anyway, it was just a suggestion to improve LLBLGenPro and if you don't feel to implement it then so be it.

Well, it's more than that, as the entity name is emitted in more than 1 statement (related entity name etc. etc.).

With v3, we'll split up the templates anyway: no longer per file but per functionality fragment, so all templates have to be re-examined, etc. anyway, so I'll re-open the item for v3 and it will then end up in the pool of features to select from for v3, so it might be done in that version when the templates are split up per feature.