Mike,

>It is simply obvious that if you have some rules in place that limit your exposure to mdot issues, that you are 1) less experienced with dealing with them and 2) limiting your environment.

I don't quite understand what experience has to do with. FYI, I did use mdot in the FP2.x days but went away from it. I know all the circumstances where to use and not to use mdot. I know all known technical details surrounding the mdot. Further I know that there are lots of less experienced or less professional people fall into the trap of not using mdot when they should. How does this make me any less experienced than anybody using mdot ??

My point is: Personally I don't see any reasons to use mdot in my projects unless there is absolute need to, because:

- Collisions of fieldnames and variables are avoided.
- It is my personal preference not too use it.

And that is the bottom line. You can agree with it or not, but that is the way I've been doing it since I started using VFP.

>However, I cannot accept the argument that "it doesn't look nice". That is childish. You are confusing "doesn't look nice" with readability. You can certainly ignore the mdots and they are no different than THIS. or any other object reference. I'm sorry you don't see the difference.

I never said, it does not look nice. I've said that it hurts MY readabilty. Partly because variables take up two characters more and the space on a horizontal line is limited. I also like to think of program lines as english sentences. m. just does not particulary fit into that.

I've already switched from mdot to not using mdot in the past, and there is not enough reason for me PERSONALLY to switch back again.

>>Don't ever smoke because you might create fire when throwing away your sigaret on the floor, even though you're always make sure you've put it out.

>Sounds practical to me. Again that is my opinion. However, how am I wrong to say that? It's only an issue with FoxPro, so when writing code in FoxPro, you are pumping gas. Not using mdot leaves a small risk, like smoking. I prefer to do everything I can to avoid that risk.

I stopped preventing all risks a long time ago. In most cases it is just not worth it. Accidents will happen no matter how well you try to prevent accidents. It is way better to use the theory of software engineering to construct software in such manner that accidents are detected (and stored in a table) and your software handles those accidented in such manner that they can be tracked and does not cause too much inconvenience to the user (so no software crashes and hangs).
Software engineering, design patterns and OO modeling also tell you how to write solid, but yet flexible programs preventing spagethi like code which ends up unmaintenable.

The above should be the goal of each VFP developper. The use of mdot is far insignificant in this case. If the above is taken care of then when a mdot collision is hidden in your software then it will:

a.: Raise an error (e.g, Type mismatch). It will be logged and reported, and eventually solved.
b.: Produce wrong output, which will be tracked (hopefully when testing), tracked and solved also.

It is not a big deal in my real world.

>You think the risk is negligible, but only because you have created an environment where the risk is lessened. That environment is a limiting factor, which reduces your exposure to mdot issues, but it does not 100% prevent them.

As I said before, the risk is negligible when using naming conventions for both fields and variables, therefore not required. So, yes, that does not apply when not using the strategy above (And I've been saying that all along, if you read my messages correctly).

>>>Your argument about readability is cosmetic, not technical.
>>
>>Writing readable sourcecode might be cosmetic, but its one of the most important factors of software development, esspecially when having more than one developer on the project. The cosmetic thing might have tremendous technical consequences.
>
>Mdot does not affect readability. However, I think it would be better to have all the developers flexible enough to handle variations in style. Suppose someone convinces you to start using norwegian notation. Will you waste your employer's money to convert everything or will you begin to use the new notation and adjust other code as necessary?

Ah, the myth of the wasted money on adapting programming styles. I'm not at all convinced that any significance is found here. There is much more time wasted on debating insignificant issues like this (How much time did we waste on discussing this subject??) or making wrong designs, tracking bugs, lack of knowledge of the problem and the environment etc. I you're a pure programmer, only programming, not doing designs, bug tracking, testing etc, then there might be a small startup costs in the programmer adapting the program style. However, this probably pays back very quickly in terms of readability.

I'm not implying that mdot is a particular important factor in programming styles. There are many, many much important factors (like commenting, Using indenting, blank lines, modular programming, etc).



>>Again, why do you want to bellitle me. I said nowhere that mdot should NOT be used EVER by NOONE. I only said that in circumstances where the no1 security measure (naming conventions) has been taken the mdot is about insignificant for a security aspect. Then it only comes down to personal preference. Go and talk to the other experience VFP developers (some of which are MVPs) who do not use mdot and say that they have limited experience in this matter.
>
>How can you not see that you are not exposed to mdots on a regular basis? That is certainly the result of limits you have imposed.

Ehh, the question is ??? Sure, I'm not frequently exposed to using mdots because I'm not using them unless neccesary. Also, you speak of limits. What limits? You mean the RULES i've got for naming fieldnames and varaiables ? I'd say you classify my rules as limits. This remembers me in C.J. DATE saying: less is more.

>You are making this whole thing personal. No one is forcing anything down your throat. Just like Howard Stern, if you don't like what is said, change the station. Don't get involved in the discussion. You admit there is a risk, but your claim that hungarian notation lessens the risk is not the same as saying that your way completely removes the risk.

I'm not living on a earthquacke sensitive area, so I've reduced the risk of beeing hit by an earthquacke. However, I'm living on about sea level. But in holland we have the 'dutch mountains' to prevent us from flooding. We have reduced the risk of beeing flooded. However if there are very rare circumstances (calculated beeing once in a 1000 years), my house could be flooded. I could leave and live upon a higher area, but I choose to take this small risk because IM CONFORTABLE WITH IT. The risk is insignificant.

About completely removing the risk: You yourself have admitted not to remove the risk entirely. If you are not using mdot for THIS and THISFORM and other objects (e.g. _VFP, _Screen) you still did not remove the risk entirely. Any way you put it, there is always risk left, even if you use it the fabio way, because then (as fabio has demonstrated) you might hit bugs because the VFP team did not test or taken care of this construct. Again, you are confortable not using mdot in front of these objects, just because the risk is insignificant.

>>Opinions generally are not forced down someone else his/her throat. I respect your opinion, but from all the messages from you regarding this subject it is not an opinion but fact or compulsory practise. My point is, that it is an opinion. I've got slighly more nuanced opinion.

>I am not forcing anything down your throat. That's your misconception, not mine.

I did never get a sence that you respected my opinion, therefore getting the impression you were trying to force something down our (my) throat. Sorry if I'm wrong here.

>My point exactly! You have no experience with mdot for the last 5 years! You have avoided mdot issues. Therefore you are not dealing with it regularly. I'm involved with it regularly because the real world contains many people that are not using any kind of notation.

And then I agree: You should analyze the situation and if the risk is unacceptable then you will have to use mdot. Then your advise makes sence, use mdot as your coding standard (but I would add, FOR THAT PROJECT".

>Regardless, when I get involved in another person's code, I will write my code so that it will have the lowest possible risk of crashing. That is my job! You are missing that point entirely. Style is over-rated,

Your opinion, not mine. I find style very important.

>especially when the other developers are unaware of the mdot problem in the first place. Would you force a left handed person to be right handed for the sake of style? Who says coding style must be uniform?

Coding style should be uniform enough. Sometimes there are circumstances that make it difficult, but it should be a goal on itself. Different coding styles within on project make it difficult to read through the code. If I find myself adjusting someone else his code, I will try to adapt his coding style.

I've heard the argument 'Who cares how the sourcecode looks like, as long as it does its job' too many times. IMO this is complete bogus. It all has to do with readability and carity of code. This is by itself one of the best defences agains coding bugs.

Therefore I could not disagree more with your statement about the insignificance of coding styles.

>I cannot guarantee my code will produce the correct results when used in various systems without mdots. You are not even producing code for use outside of your own system. That too is a limiting factor.

Again, I do.... My personal framework is in use by two other vendors.

>I'm sorry you're taking this personally, but there is no way you can deny that you are not experiencing mdot related bugs as regularly as I am.

True,

>Therefore you have limited experience with them. Therefore your claim that they are insignificant is not applicable to others.

If you read my posts carefully, I did state the circumstances under which mdot is insignificant. And I did state that mdot is significant when those circumstances are NOT met. Please don't misstate me.

Again, I can't follow you. What is the significance of 'experience' when 'experience' means the number of times you've encountered a problem ??? Then we better talk about knowledge. I can safely say that my knowledge about mdot related problems is a well as yours, though I have less 'experience' with it.

You're trying to create authority because of your experience, while you should create authority based on your knowledge. Experience <> Knowledge. You can beat me on experience, but I would no say the same on knowledge. Maybe we should even take it one level up: Understanding.

Experience <> Analysis <> Knowledge <> Understanding <> Creativity.

Walter,