Sparx Systems Forum
Enterprise Architect => Suggestions and Requests => Topic started by: gtschech on March 23, 2006, 11:29:24 pm
-
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
-
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
-
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
-
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.
-
Sorry Guenter,
There is currently no way to configure the code synchronisation to recognise two attributes with a different name as the same thing.
-
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
-
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! ;D
You must be serious about this since you signed it: "Bruce" and not your usual "bruce". ;)
Let the games begin! :P
Paolo
-
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
-
Didn't Visual Age for Java (optionally) automatically prefix names of member variables with "m_" ?
It's a (well?)known convention ...
-
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
-
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.
-
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
-
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
-
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!
-
;) Oh, so t h a t ' s why it wont compile ;)
b
-
;) Oh, so t h a t ' s why it wont compile ;)
b
Did you like my new word for the day?
Procrustean ;)
I saw it in another publication, looked it up, and it was so apposite I was able to use it in the response not half an hour later! - Fate! 8)
Paolo
-
bruce & paolo,
I totally agree wiht you that naming standards by themselves do not enforce any quality of code.
In my case the development team has discussed a lot of naming standards (casing, prefixing, naming) and yes, we had some requirements.
Briefly spoken, it's just 2 of them
a) the code must be readable -> variable names should primarily reflect their content or primary use, not their data type or things like that
b) the names should be optimized for IntelliSense, for since I work with VisualStudio.NET, I can't remember having typed a single variable name to it's end before hitting "tab" for autocomplete-ing :)
Both requirements led us to - as I think - reasonable guidelines.
But one of them is that we feel it should be immediately visible if a variable is a local variable or a class-level variable. Of course, we could have agreed on adding "this.", but isn't that another kind of prefix? (and besides that, it's much longer than "m_"...).
So the coding guys are all satisified, and the only problem is the model.
Even here all participants have the same understanding that coding-specific prefixes should not be visible in the model, so up comes my problem...
Guenter
-
Guenter,
The problem occurs because your Class model in EA doesn't reflect your Class model in code.
I agree that the adornments shouldn't be seen in the model - at the conceptual and logical levels (whatever they mean - I know, but do you have the same understanding? ;-) ). Let's call these Non-Platform-Specific-Models. However, at the PSM level it seems to me essential that the two class models are identical, as far as is possible).
Remember, I'm not a big fan yet of Round-Trip-Engineering (see my postings elsewhere). However IF you ARE going to attempt it, the two models should be as identical as you can make them.
It seems to me that you need to have two models: the CIM and/or PIM models - which don't have adornments and the PSM that you use to generate and synchronize code with. You need a transformer to go from the PSM and back.
Fortunately, EA has such beasts.
Your transformation would add any appropriate adornments and changes (often caused by "impedance mismatch" between the PIM and PSM) between the two models.
HTH,
Paolo
-
Hi paolo,
now there are those acronyms I wanted to avoid ;)
I am not sure whether my project deadline will allow me to dig into the PIM/PSM transforming stuff.
From my experiences with EA roundtrip engineering (some years ago I used V4, now V6 for about 3 months) I believe it can be done, but haven't looked into it yet.
It seems like I'm going to live with my adornments in the model and keep the beautifying (i.e. separation of PIM and PSM as well asl round-tripping) to a later project step.
Nevertheless: I'd be glad if you could point me to some helpful discussion of the transformation process (some good keywords for the forum serarch would do nicely, thank you :) )
guenter
-
Perhaps another 0.01 CAD worth, to add to the other one I threw in earlier.
Meanwhile I'll remind you of what I said earlier. If you are going to have two levels of abstraction - regardless of how close or far they are from each other - you need to have two presentations within your model.
You mention that prefixes should not be visible in the model. However, you want clear, readable code. I will stick my neck out here and guess that you also want the code to compile as you specify.
I am going to stay well away from the methodology stuff here. I do strongly agree with what is being said there, but you are in the middle of something, and research, selection, adoption, and implementation of a methodology might, within the scope of your current project, negatively affect your critical path.
If you want some portion of your model to accurately map to the code you will need, at least in this model portion, to have the prefixes, or whatever, show up in the model.
[b[If[/b] you want some portion of the model to allow (some of) your audience to review the 'pure' structure without adornments, you will need, at least in support of this model portion, to conceive a mapping between the 'pure' structure and what is in the portion of the model that directly reflects the physical system.
That mapping can be realized in a transform. In your case it, as you describe your needs, this would seem to be very limited in scope and complexity. If the overall size of your model is not too tiny, then this could well pay off immediately, since you can keep the two portions in synch, and may even be able to model one 'side' and generate the other through the transform. If your model is small, then this step will probably be quite quick, and could fit within your schedule - possibly offset by reduced time needed for hair-pulling.
You could even model the components of the transformation itself, giving you a way to examine your 'in-house standards' as well as publishing the expected results, audiences, and benefits. Who knows, your various communities might actually come up with a set they could all work with...
David
-
Guenter,
The only thing I can add to David's (excellent) comments is that if you really can't afford 2 presentations at this time, then the one to go for now is the PSM - code and model align. Later you can create the more "presentable" version, via the transforms.
In a sense, this conforms to the Agile adage: "Prefer working code to documentation".
Paolo
-
Or more to the point, if the code won't compile, then the management presentation can be deferred. When it comes time to explain which half you concentrated the limited resources on, much will be forgiven if the code works.
-
...
Nevertheless: I'd be glad if you could point me to some helpful discussion of the transformation process (some good keywords for the forum serarch would do nicely, thank you :) )
guenter
Guenter,
I'm currently not using EA (in anger - I'm on a different project where a different DB modelling tool is used)
I've also not yet got into the tranformation processes in EA as much as I'd like, so I won't be much help with keywords. However, I'm sure you can check it out yourself.
Paolo
-
Hi paolo,
now there are those acronyms I wanted to avoid ;)
I am not sure whether my project deadline will allow me to dig into the PIM/PSM transforming stuff.
From my experiences with EA roundtrip engineering (some years ago I used V4, now V6 for about 3 months) I believe it can be done, but haven't looked into it yet.
It seems like I'm going to live with my adornments in the model and keep the beautifying (i.e. separation of PIM and PSM as well asl round-tripping) to a later project step.
Nevertheless: I'd be glad if you could point me to some helpful discussion of the transformation process (some good keywords for the forum serarch would do nicely, thank you :) )
guenter
Hi Guenter, I currently have some spare time and also work with Transformation. So you might give me a ping and we even could discuss this a bit by phone. (I'm located in greater Berlin area)
Edit:Btw: Naming conventions? Why aren't you talking about indentation? ;D
-
Paolo, could you share with us your adopted naming conventions?
-
Paolo, could you share with us your adopted naming conventions?
Well SF_lt,
I did observe that everyone's situation is different and so I would be, to some extent, going against my own admonition to do that. However, I can discuss some of the principles I have adduced and have helped me in arriving at my conventions. I'm sure I'll learn something in the discussions and it will help me improve my own standards.
If this is agreeable, I can start up some separate threads (say in the UML forum - since that seems to be the most appropriate), each one dealing with some aspect of naming.
I think this would give readers the best "bang for the buck".
Let me know if anyone is interested...
HTH,
Paolo
-
of course, count me in ;D
-
Me 2
Guenter
-
And I.
-
Me too
-
Sorry, I've been a bit too busy to get back here and apologise to Guenter.
I overreacted to the word "policy" in his original post. In reality what he is discussing is, let me call it, a team ethic rather than a corporate policy. In which case I am all for it!
Similarly, Paolo's own convention is again an ethic rather than a panacaea.
Ethics are tribal, local and generally transient. They evolve and continue to contribute to the tribe achieveing its goals in a manner deemed efficient to local observers. In short they do add value.
Policies, especially IT policies in my observance are generally static, outdated and valueless from the outset. (Go on, bite!)
bruce
p.s. Paolo - me too!
-
Off topic: Bruce, have you found a way to transport electricity over IP and now start counting the Volts? ;D
-
http://www.faqs.org/rfcs/rfc3251.html ;D
-
It's April - every year :D