Author Topic: Naming Architectures - Why? (Read 9546 times)

Paolo F Cantoni · « **on:** April 04, 2006, 05:44:37 am »

This is the first of a series of postings on principles for naming things (in models and in code). It is the result of an offer I made in the thread: [size=13]customize code engineering?[/size]; which dealt with the problem of trying to synchronise model names and code names where they aren't the same.

In that thread, I made a plea for developers of naming standards to define requirements first and then supply reasons why their naming architectures were the way they are. Since it would be inappropriate to assume my personal naming architecture would apply to someone else's situation, I suggested some posting on some of the principles I've adduced and have found useful in developing my architecture.

I'd like there to be robust discussion, so I can learn. I suspect we will be able to develop a pattern language for Naming similar to other pattern languages (such as an excellent one for Use Cases or one I've referenced in other postings regarding User Interface design.

[size=18]Why have naming rules?[/size]

So this thread is about the reasons why we should have naming rules...

I'll throw it open with...

[size=24]MaintainNamingStandards[/size]
[size=16]Context:[/size]
[size=13]In any systems project, there are elements that must be named to differentiate one from another.[/size]
[size=16]Issue(s):[/size]
[size=13]

... (Here we will list issues that a good naming standard has helped to resolve)
Compromises made to align the many different points of view may result in a less than satisfactory naming architecture.
... Here we will list issues that a bad naming standard has created

[/font][/size][/color]
[size=16]Force(s):[/size]
[size=13]

Different tools and languages have different syntaxes
Different project needs may require different levels of conformance
Arbitrary rules make adherence difficult
Rules that have practical benefits make adherence easier

[/font][/size][/color]
[size=16]Therefore:[/size]
[size=13]Develop and maintain a naming architecture[/size]
[size=16]Discussion:[/size]
[size=13]This pattern should evolve as a result of the thread discussion. I'll periodically update it as a result your input. This first posting will edited as the pattern evolves.[/size]

SF_lt · « **Reply #1 on:** April 05, 2006, 01:11:32 pm »

Paolo, I hope, that you'll enjoy the same as I did while reading this

Besides, this has deep relations with your posted topics and idea

http://thc.org/root/phun/unmaintain.html

Paolo F Cantoni · « **Reply #2 on:** April 05, 2006, 08:13:14 pm »

Quote

Paolo, I hope, that you'll enjoy the same as I did while reading this
Besides, this has deep relations with your posted topics and idea

http://thc.org/root/phun/unmaintain.html

Yes I did thanks, SF_lt.

I've added it to my favourites.

As usual, there's a lot of truth in humour...

Paolo

jeshaw2 · « **Reply #3 on:** April 06, 2006, 06:14:18 pm »

The American Aboriginals (Indians) have a saying that "to control a man and his spirit, you must first know his name." Thus, the Indians have two names, a public name for general reference, and a hidden name for use only by dearly loved and trusted friends and family.

Moral of this story: Once you have given an appropriate name to an attribute or operation, Mark it as PRIVATE! That's whot encapsulation is all about

So what should we use for public names? *hehe*

sargasso · « **Reply #4 on:** April 06, 2006, 07:22:02 pm »

I once had a code cutter who took great pride in proving that he could write an entire program using only the variables "Y" and "Y$".

I didn't have him long.

b

jeshaw2 · « **Reply #5 on:** April 06, 2006, 07:39:14 pm »

b-

I'll see you on that one and raise you another.

In the first month of my career as a programmer, the guy at the desk next to mine developed a 360 Assembler language program using only relative addressing (*+n and *-n). The "n"s are mine; actually he used a numeric constant in place of the "n". Of course, at each statement, the value of * (the current value of the program address counter in the PSW) was changed. The final code was approximately 35 pages long!

Management applauded his achievement!

As the least senior programmer, I got out before I was assigned the job of maintaining that code

sargasso · « **Reply #6 on:** April 06, 2006, 08:30:03 pm »

...
LDB stringvar+[RX]
DRB #60
MVB RX
LDA @mapoffset+[RB]
STA *+1
JMP

Now that's my claim-to-fame. It replaced ~50 lines of FORTRAN IV and ran at lightspeed.... but when it was wrong it leapt beautifuly right into the centre of the unrpotected operating system.....

(Simply it takes a character out of string, generates an index value from the ascii value, shoves that in the index register. Then it loads a value from an address pointed to in the 'mapoffset' table into reg A, stores that value (which is hopefully an address in the current space) into the code in the word following the JMP instruction..... i.e. the jump target. Then execute the jump and hey presto you're in an entirely new instruction set!)
Evil, evil code that self modifies at run time. HAHAAHAHA

b

mikewhit · « **Reply #7 on:** April 07, 2006, 12:47:44 am »

Was the instruction set missing a jump-indirect operation ?

Should have really done a bounds check on the byte, or made the lookup table big enough and filled it out with a 'do nothing' destination address ...

The only recent time I have seen real self modifying code was for a x86 processor to determine the length of its prefetch queue - if the mod wasn't seen, it had obviously already been prefetched at that point !

Some early systems (50's and 60's) allegedly did subroutine calls by storing the return address in the first location of the subroutine - obviously you couldn't have a call depth to any function of more than one.

thomaskilian · « **Reply #8 on:** April 07, 2006, 02:45:52 pm »

Quote

b-

I'll see you on that one and raise you another.

In the first month of my career as a programmer, the guy at the desk next to mine developed a 360 Assembler language program using only relative addressing (*+n and *-n). The "n"s are mine; actually he used a numeric constant in place of the "n". Of course, at each statement, the value of * (the current value of the program address counter in the PSW) was changed. The final code was approximately 35 pages long!

Management applauded his achievement!

As the least senior programmer, I got out before I was assigned the job of maintaining that code

I'd run a disassembly and maintain that. The label would be cryptic but at least better understandable than *-/-n. Btw.: why the applause? Where they happy that the assembler just took 5 instead of 6 seconds to assemble

jeshaw2 · « **Reply #9 on:** April 07, 2006, 05:50:18 pm »

It was a bank who was developing software for their auditor to use. They did not want to reveal the logic of the software. This was back in 1969. The IBM 360/20 had just been released. Remember the old MFCM machine?

thomaskilian · « **Reply #10 on:** April 08, 2006, 11:43:11 am »

Hi Jim,
I'm an oldie, but you're obviously a dinosaur

I started with /370 but still feel the fun I had

I had my own "MFC" written in /370 assemble ages before MS actually thougt of writing something alike. Aaaah - I must take a cold shower

sargasso · « **Reply #11 on:** April 09, 2006, 03:58:35 pm »

Quote

Was the instruction set missing a jump-indirect operation ?

Well done!

It was actuall the indexed indirect that was missing, but nicely picked.

b

Bruno.Cossi · « **Reply #12 on:** May 03, 2006, 06:28:07 am »

Link to WIKI where Paolo started publuishing his series on this topic:

http://wiki.eausergroup.org/index.php?title=Naming_Conventions

Bruno

Sparx Systems Forum

News: