customize code engineering?

[gtschech]

I am using Sparx EA to design C# applications.
My company has a policy thast every class level variable has to start with an "m_" prefix.
For my class model, I would rather have no prefix on each and every attribute just for the sake of C# naming conventions.
I found a way to insert the "m_" prefix inside the "Attribute Declaration" Code generation template, but each time the code generation runs again it deletes the m_ variables and inserts a new set.
I believe this is due to the fact EA doesn't recognize the m_ variables as the ones it generated last time.

Is there a way to get EA to automatically insert and strip the m_ on code synchronisation?

Guenter from Frankfurt/Germany

[«Midnight»]

Hi Guenter,

You don't say which way you found, so I'm guessing here. I also confess that I don't round-trip C#, so have not tested this.

Look at the Tools / Options dialog. Click Source Code Engineering (not the individual languages underneath). There is a list of prefixes that will be used and stripped during code generation. Make sure to separate them with semicolons (on some monitors you can mistake these for commas). I also make sure there is a semicolon after the final entry, but cannot remember if this is necessary.

HTH, David

[gtschech]

Hi David,

the method I used was to modify the code generation template for C# attributes, where the "m_" is inserted as a literal.
Your suggestion does not work, because I do not want to strip something, but rather insert it duringe code generation, and have it stripped on reverse engineering.

As far as I found, your suggestion does just the opposite...
Am I right?

Guenter

[«Midnight»]

Sort of...

Do you mean you want the actual code to have a class-level variable named "m_something", but which the model will show it as simply "something"?

In this case we're in trouble with my suggestion. What EA tries to do in that case is allow the model to have a class-level variable named "m_something" but to create (one or more, as appropriate) properties named "something" (or I thnik, depending on other settings, "Something").

From your original message I assumed (my bad if incorrectly) that is what you were trying to do to meet your company's policy.

[Eve]

Sorry Guenter,

There is currently no way to configure the code synchronisation to recognise two attributes with a different name as the same thing.

[sargasso]

One must wonder what level of higher intelligence is needed to hire code police to make sure that ENTIRELY internal variables declared in code all have EXACTKLY THE SAME prefix.

I, as an ordinary Venusian code jerker, cannot for the life of me understand exactly what value has been added to the corporate balance sheet by enacting this rule.

Its a wonder they dont edict that all internal variables be named "m_var" just to avoid confusion.


best of luck
Bruce

[Paolo F Cantoni]

One must wonder what level of higher intelligence is needed to hire code police to make sure that ENTIRELY internal variables declared in code all have EXACTLY THE SAME prefix.

I, as an ordinary Venusian code jerker, cannot for the life of me understand exactly what value has been added to the corporate balance sheet by enacting this rule.

Its a wonder they don't edict that all internal variables be named "m_var" just to avoid confusion.


best of luck
Bruce

OOOH... Now you've set the cat among the pigeons!  

You must be serious about this since you signed it:  "Bruce" and not your usual "bruce".  

Let the games begin!      

Paolo

[gtschech]

One must wonder what level of higher intelligence is needed to hire code police to make sure that ENTIRELY internal variables declared in code all have EXACTKLY THE SAME prefix.
...
best of luck
Bruce

Bruce,

I cannot fully understand your intention, but to me/us it seems ok to force a policy to prefix all class-level variables with an 'm_' to distinguish between local and class-level variables in code. It simply makes code better readable in our mind.

But nevertheless, I'd like to have my UML model to have just the plain variable names (without prefix), because in UML you can *see* the difference...

@Simonm:
I do not want Sparx to treat two things as the same, but to have one notation in the UML model (without 'm_) and another in the generated code (with 'm_'). IN the respective domains all variable names are unique.

That said, I understand that I will have to live with one or the other side being less than perfect  

Guenter

[mikewhit]

Didn't Visual Age for Java (optionally) automatically prefix names of member variables with "m_" ?

It's a (well?)known convention ...

[«Midnight»]

None of you will really like this, but my hope is that all of you will be more or less equally unsatisfied, as will I. [Being Canadian, this is a natural compromise to me.   ]

You could always give the attributes and alias as well as a name. Now, since (for some reason) there appears no way to display the alias of an attribute (vs. a classifier) on a diagram, you will have to reverse the two. Now the name (acutally the alias, to us in the know) will show on the diagram, while the alias (actually the name) will be hidden, but accurately depict the attribute name in code.

You'll have to tweak the generation scripts to use the attribute as the variable name (if this is not already availble), but that should not be too difficult.

Of course, since you seem to want to display one 'model' while using another, for purposes of ease of understanding, we could construe this as two different levels of abstraction. Perhaps you should create one model for display and another for lower-level work including generation. You could implement some kind of 'trace-ish' relationship between the models.

[You'll want to read posts by myself and others concerning how attributes are displayed. Start by searching on "attributes" in Suggestions and Requests over the past few months, and go from there. Sparx has yet to bite - hint, hint...]

There's plenty of ways to go about something like this, some of which might be easier to impelement than others. Look at some of the methodologies (at some level of abstraction and completeness). I try to be methodology-agnostic on this forum, so I'll bait that hook but not take another bite.

OK Bruce and Paolo, stop holding your breath. Let the gemes begin!

David

[Eve]

Guenter,

The two attributes that I was talking about being the same are the model attribute (eg. something) and the code attribute (eg m_something).  In order for code synchronisation to work in either direction EA needs to recognise that those two match.

As they have different names they never will match according to EA.  Setting the alias of the attribute in the model to something and enabling 'Use Alias if Available' on your diagrams seems like the best available solution.

[gtschech]

Simon,

thanks for the info about aliases.
I think I'll be using this alternative. Now I'll just have to find out how to modify my document template so it uses the alias in print, but I think that's not really magic...

yours
Guenter

[sargasso]

I cannot fully understand your intention,

Guenter,

It was a pretty (petty) personal comment.  After 25 years of IT I can only state that in my experience sticking prefixes on the front of variables to denote type/scope/whatever add absolutely $0.00 to the value of the code, its' correctness or its' ease of maintenance.

OTOH the cost of implementing L.A.W.s like this, again IME, is considerable.  What coders and code reviewers should be looking for is CORRECT code not whether I have a class level variable with a correct name shape.

private int m_semitrailercheesetray = -1;


if ((bool)m_semitrailercheestray) {
   do_something();
}


bruce

[Paolo F Cantoni]

Guenter,

It was a pretty (petty) personal comment.  After 25 years of IT I can only state that in my experience sticking prefixes on the front of variables to denote type/scope/whatever add absolutely $0.00 to the value of the code, its' correctness or its' ease of maintenance.

OTOH the cost of implementing L.A.W.s like this, again IME, is considerable.  What coders and code reviewers should be looking for is CORRECT code not whether I have a class level variable with a correct name shape.

private int m_semitrailercheesetray = -1;


if ((bool)m_semitrailercheestray) {
    do_something();
}


bruce

Well, bruce

I have to agree that in my (see your 25 and raise 5) years of observing code (I haven't written that much of it), your observation that procrustean adherence to coding standards hasn't added significantly to the quality of the code produced is pretty valid.

From my observations, there are a number of reasons for this:
Naming and adornment standards that are arbitrary.  That is, slavishly applied without thinking about why the rules are there (and particularly without explanation of why the rule is there)
and..
Incorrect application of the rules (for example fully 90% of "Hungarian" notation is incorrectly implemented - regardless of what you think about the concept.


However, that doesn't mean that the the adoption of a naming and (particularly) adornment standard is, of itself, bad.

For my own part, I have a a strict naming and adornment standard that was developed after firstly sitting down and defining a set of requirements for what the outcomes needed to be.  (As far as I know, I'm the only person to have every done that - if anyone knows of any formal specification for a naming standard let me know as (obviously) I'm keenly interested in it)

The standard has problems because it cuts across many existing "L.A.W.S.", but it works for me.  It's not widely adopted because it is so radical.  However, when promoting it, when I'm criticised, I often ask my interlocutor if they adhere to the "rule" they are proposing.  All to often, the answer is no...  If you don't have the courage of your convictions...

So, my plea is:  Before adopting a naming and adornment standard, first decide on what the requirements are for your situation.  Then, compare and contrast any proposal against the requirements set.  For each rule, establish why it exists and what the benefits are...

(and for the record, my standard does have specific adornments for private member attrivbutes - as distinct from public member properties)

Paolo

BTW: It may not have been obvious to the L.A.W.S. adherents that your example was "tongue in cheek!".

and you mispelled the variable in the second instance!

[sargasso]

  Oh, so   t h a t ' s  why it wont compile  
b