1 #include "sy.h" 2 Extern int *rgwDic; 3 extern int bsyMac; 4 struct SY *PsySz(sz) 5 char sz[]; 6 { 7 char *pch; 8 int cch; 9 struct SY *psy, *PsyCreate();10 int *pbsy;11 int cwSz;12 unsigned wHash=0;13 pch=sz;14 while (*pch!=015 wHash=(wHash>>5)+(wHash>>11+*pch++;16 cch=pch-sz;17 pbsy=&rgbsyHash[(wHash&077777)%cwHash];18 for (; *pbsy!=0; pbsy = &psy->bsyNext)19 {20 char *szSy;21 szSy= (psy=(struct SY *)&rgwDic[*pbsy])->sz;22 pch=sz;23 while (*pch==*szSy++)24 {25 if (*pch++==0)26 return (psy);27 }28 }29 cwSz=0;30 if (cch>=2)31 cwSz=(cch-2/sizeof(int)+1;32 *pbsy=(int *)(psy=PsyCreate(cwSY+cwSz))-rgwDic;33 Zero((int *)psy,cwSY);34 bltbyte(sz, psy->sz, cch+1);35 return(psy);36 }Hungarian Notation - no longer necessary?
I''m too lazy to read the entire thread, so I just read the first post. Hungarian notion is a waste, because it actually makes code worse to read, and gets you locked into particular types. I choose variable names based on responsibility, not type. I do happen to prefix member variables with _ rather than m_. This is just because I like to keep any prefixes as short as possible, there isn''t a need to put an m in front of it.
And as far as pointers go, if I were to be programming in C++ I would probably use some sort of smart pointer / reference system that encapsulates any specific pointer stuff, then I don''t need to worry about whether I am dealing with a pointer or dealing with actual stuff.
And as far as pointers go, if I were to be programming in C++ I would probably use some sort of smart pointer / reference system that encapsulates any specific pointer stuff, then I don''t need to worry about whether I am dealing with a pointer or dealing with actual stuff.
quote:
then I don''t need to worry about whether I am dealing with a pointer or dealing with actual stuff.
You ALWAYS need to know if you''re dealing with a pointer or with "actual stuff". And encapsulating pointers isn''t always the best (or even a very good) option, but I digress...
quote:Original post by Etnuquote:
then I don''t need to worry about whether I am dealing with a pointer or dealing with actual stuff.
You ALWAYS need to know if you''re dealing with a pointer or with "actual stuff". And encapsulating pointers isn''t always the best (or even a very good) option, but I digress...
I guess you didn''t see my previous post, so I will summarize:
Why not just use the IDE along with your comments for types?
quote:Original post by Arild Finesquote:Original post by Verg
Now that's not a horrificly poor piece of code, but it's not a laughable example either. But when locals are littered all over classes like that... that's just laziness.
Nope, it's sound software engineering.
Baloney
It means that you're inserting structures and variable unrelated to the class in a quick and dirty way to get the functionality. If you need the functionality, compose your class better.
quote:quote:
Why not factor those locals back into the class, or even the base class?
Because there is no reason to. It's as simple as that. These variables are not part of the object's state.
*ANY* variable should be accessible in as small a scope as possible. IE, prefer a module-level variable to a global, prefer a class variable to a module variable, prefer a local/parameter to a class variable.
Again, baloney. When you're passing strings of 6 parameters into a function, or using several locals in a function, it means that your class isn't well designed in the first place. The code that it needs either isn't in it, or shouldn't be in it.
One of the greatest advantages of data members is not having to pass them in as parameters. Think about that when optimizing 100 function calls that take 5 paramaters each.
If you factor the locals back into the members list, and take a look at it... you'll likely see a lot of unrelated data types and structures there. These are responsibilities (in most cases) for separate classes. It's time to split your class into smaller classes, by responsibilities.
Think "smallest pieces that vary". That will help manage any project you have.
quote:
Read up on "encapsulation". Something tells me you missed the clue train when it comes to programming with classes.
Don't go there
Data that is related to each other should be kept in the same place; classes using unrelated data types and responsibilities says someone needs to read Martin's book on refactoring. [edited by - Verg on June 11, 2004 8:10:40 PM]
[edited by - Verg on June 11, 2004 8:14:10 PM]
[edited by - Verg on June 11, 2004 8:15:15 PM]
quote:Original post by Verg
Baloney
BS. You are keeping data close to the point where it is needed, restraining it''s lifespan to what is required.
quote:
One of the greatest advantages of data members is not having to pass them in as parameters. Think about that when optimizing 100 function calls that take 5 paramaters each.
There''s a micro-optimization if I ever heard of one. I don''t think you get to advice micro-optimizations AND invoke the mighty Fowler in the same post.
quote:
If you factor the locals back into the members list, and take a look at it... you''ll likely see a lot of unrelated data types and structures there. These are responsibilities (in most cases) for separate classes. It''s time to split your class into smaller classes, by responsibilities.
This is just taking sound advice to the silliest extreme. None of your examples so far has been convincing in the least bit. You have consistently failed to show in any why it is preferrable to give data that really should have been locals the lifetime and scope of their enclosing classes.
quote:
Don''t go there
AND in the scope where they are needed.
quote:
classes using unrelated data types and responsibilities says someone needs to read Martin''s book on refactoring.
I have a copy here on my shelf, and I''ve read it several times. I''m fairly sure Fowler doesn''t say anything about totally discarding locals in favor of class members.
Perhaps *you* better read it again, and not the same way a certain horned creature reads the bible this time?
quote:Original post by Arild Finesquote:Original post by Verg
Baloney
BS. You are keeping data close to the point where it is needed, restraining it's lifespan to what is required.
Which is exactly the point of splitting the class into smaller classes. If that data were in its OWN class, it could manage itself. Plus, you have it to reuse later.
quote:quote:
One of the greatest advantages of data members is not having to pass them in as parameters. Think about that when optimizing 100 function calls that take 5 paramaters each.
There's a micro-optimization if I ever heard of one. I don't think you get to advice micro-optimizations AND invoke the mighty Fowler in the same post.
Or 1000 or 10,000 times. Whatever. It's still slower, and indicative of the need to refactor.
quote:quote:
If you factor the locals back into the members list, and take a look at it... you'll likely see a lot of unrelated data types and structures there. These are responsibilities (in most cases) for separate classes. It's time to split your class into smaller classes, by responsibilities.
This is just taking sound advice to the silliest extreme. None of your examples so far has been convincing in the least bit. You have consistently failed to show in any why it is preferrable to give data that really should have been locals the lifetime and scope of their enclosing classes.
It's not! It's a step in refactoring. Once you look at that list of unrelated data types, it will be easier to split the class -- which was my point.
quote:quote:
Don't go there
AND in the scope where they are needed.
..inside a new class... which can be re-used
quote:quote:
classes using unrelated data types and responsibilities says someone needs to read Martin's book on refactoring.
I have a copy here on my shelf, and I've read it several times. I'm fairly sure Fowler doesn't say anything about totally discarding locals in favor of class members.
Perhaps *you* better read it again, and not the same way a certain horned creature reads the bible this time?
Ha ha.
Look, I didn't "thumbs down" on you; I'm responding. If the object's state is unrelated to the data (data that it is managing) that data shouldn't be in that class. Another class that "encapsulates" that scope should do it. Then, aggregate an object of that class. Simple. It's just sound OOP design and priciple.
Chad
[edited by - Verg on June 11, 2004 8:38:21 PM]
Ugh, someone talked of using "lp" to denote pointers. "Oh, thats a long pointer, now it all makes sense!"
I dropped using the p prefix on pointers awhile ago and I really don''t miss it. If you cannot remember what the actual type of a variable is, some refactoring should be in order. Additionally, most systems decide upon references/pointers and then use that across the board. For example, a class responsibility may be changed due to a new requirement and one way to enforce a non-null pointer at compile time is through use of a reference. Switching from a pointer to a reference necessitates a global search and replace when using a p prefix -- which, hopefully, is safe to blindly run on an entire file.
I''ll probably drop the m_ prefix in time, as well, and not use anything to identify class members. If you want to disfigure your code with every conceivable acronym you can squeeze in there, be my guest. I''ll make sure to avoid it.
Also, I say we start an army devoted to the elimination of CClassname and its uglier twin, cClassname.
I dropped using the p prefix on pointers awhile ago and I really don''t miss it. If you cannot remember what the actual type of a variable is, some refactoring should be in order. Additionally, most systems decide upon references/pointers and then use that across the board. For example, a class responsibility may be changed due to a new requirement and one way to enforce a non-null pointer at compile time is through use of a reference. Switching from a pointer to a reference necessitates a global search and replace when using a p prefix -- which, hopefully, is safe to blindly run on an entire file.
I''ll probably drop the m_ prefix in time, as well, and not use anything to identify class members. If you want to disfigure your code with every conceivable acronym you can squeeze in there, be my guest. I''ll make sure to avoid it.
Also, I say we start an army devoted to the elimination of CClassname and its uglier twin, cClassname.
Verg:
You seem to be drinking a lot of the OOP kool-aid. Do you honestly think that OOP has achieved its much-hyped goal of reusable objects that we can make new applications out of like Legos? I see no benefit in packaging together data if:
a. there is no invariant that must be held across the lifetime of the object
b. the data is only used in very few places
c. it doesn''t conceptually make sense
For even a small application you would generate lots of little classes in the name of OOP purity. And what exactly would you get out of it?
I''ll leave that as a rhetorical question.
You seem to be drinking a lot of the OOP kool-aid. Do you honestly think that OOP has achieved its much-hyped goal of reusable objects that we can make new applications out of like Legos? I see no benefit in packaging together data if:
a. there is no invariant that must be held across the lifetime of the object
b. the data is only used in very few places
c. it doesn''t conceptually make sense
For even a small application you would generate lots of little classes in the name of OOP purity. And what exactly would you get out of it?
I''ll leave that as a rhetorical question.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
