New funcionality proposal

[Jacek Laskowski 57]

I have a proposal for a new functionality for MMX. It is a simple change, and for me, and I hope other users too, can be very useful.

I use prefixes in the names of method parameters, I personally prefer the letters a, o and v for const, out and var parameters, respectively:

procedure Somethinghing(const aInput : Integer; out oOutput : string; var vOther : string);

Thanks to this, inside the body of the method, I know which parameter has which features and whether I can (var) or should (out) change it. This greatly improves code readability and error avoidance. Of course I write about myself 😉

 

I suggest adding a function to MMX that could be called "Forcing a parameter name prefix". Of course, the prefix (a, c and o) themselves could be set in the MMX configuration (just like the prefix for object fields).

Additionally, in the configuration I would also give a checkbox "Force parameter name prefix", which would be the default value when editing the method (ctrl+E) and which could be incidentally unchecked or checked as in the picture:

 

 

Using the "force prefix" option would work in such a way that if the parameter has some prefix (lowercase letters in front, before uppercase) they would be replaced, e.g. xParam -> aParam, xyParam -> aParam, and if the parameter has no prefix then it would be added, Param -> aParam

 

Does this idea seem good to you and you would take it up?

 

Edited October 14, 2020 by Jacek Laskowski

[Stano 143]

Hungarian notation is said to no longer be used in OOP.

[Lars Fosdal 1793]

All my method arguments start with a - regardless of if they are const, var or out.

[Jacek Laskowski 57]

9 minutes ago, Stano said:

Hungarian notation is said to no longer be used in OOP.

The Hungarian notation refers to prefixes identifying the type of variable, this is something else.

3 minutes ago, Lars Fosdal said:

All my method arguments start with a - regardless of if they are const, var or out.

In this case you would have all 3 kinds of prefixes marked as 'a'.

[Stano 143]

The Hungarian notation refers to prefixes identifying the type of variable, this is something else.

OK.

If I use the prefix to avoid collisions with variables, then only "A". So how Lars Fosdal.

[Jacek Laskowski 57]

9 minutes ago, Stano said:

The Hungarian notation refers to prefixes identifying the type of variable, this is something else.

OK.

If I use the prefix to avoid collisions with variables, then only "A". So how Lars Fosdal.

As I wrote in the first post this functionality would be optional and configurable.

[Uwe Raabe 2064]

The configuration may lead to a big ball of mud quickly. Just your suggestion 

2 hours ago, Jacek Laskowski said:

if the parameter has some prefix (lowercase letters in front, before uppercase) they would be replaced

assumes that anyone uses lower case prefixes in the first place. I have seen some significant number of coding style guides that prefer the capital letter A.

 

While I can see the benefit for your personal case, I expect difficulties to make it suitable for the general audience.

[Jacek Laskowski 57]

40 minutes ago, Uwe Raabe said:

The configuration may lead to a big ball of mud quickly. Just your suggestion 

assumes that anyone uses lower case prefixes in the first place. I have seen some significant number of coding style guides that prefer the capital letter A.

 

While I can see the benefit for your personal case, I expect difficulties to make it suitable for the general audience.

 

Ok, I actually assumed that everyone uses lower case letters as prefixes
But let's think about the cases.
Let's assume that we want to use the letter 'a' as a prefix, in which case all the possibilities of the end result are:

name -> aname
Name -> aName
Array -> aArray
array -> aarray ??

When the beginning of the name already contains a small 'a' (in case of re-editing), it is enough to check if the beginning is consistent with 'a', only the last example introduces an ambiguity, because 'array' starts with 'a' and it is not known if it is a 'rray' with an added prefix or 'array' without a prefix.
In this case, I would leave 'array' unchanged (which works well for editing the aarray parameter as well).

 

The case with the prefix written in capital letters 'A':

name -> Aname
Name -> AName
Array -> AArray ??
array -> Aarray

In this case, the third case (Array) is ambiguous. I would leave it unchanged, similarly as above.

 

These conditions do not seem very complicated, have I overlooked something?

[Guest]

+1 for Uwe.

 

When you write a procedure for the first time you tend to use your own style, it is habit and old habit never die, so instead of above suggestion i would suggest something else.

 

A new functionality where you can select multiple procedure/functions (can be select all) then click edit parameters, a new window with TListView or something else will open, something with three columns, listing all the parameters and their types for all the selected p/f, now simply you can rename/edit anything there, then click OK, this can be useful refactor your code or any code.

[Jacek Laskowski 57]

@Kas Ob.

Maybe you should put on a new thread with your proposal, this one concerns my proposal, ok?

[Guest]

4 minutes ago, Jacek Laskowski said:

Maybe you should put on a new thread with your proposal, this one concerns my proposal, ok?

I am not hijacking anything here, i confirm your point is usable, put lets look at this in different way.

 

1) Forcing new style or behaviour on a tool been used for years will not fly but adding new functionality will do.

2) Lets trick Uwe to do my suggestion first, then in the new window/functionality, we will nag him to make add all sort of styles there, yours and others.

 

Will that do ?

 

Away from that i am sorry if my suggestion was offending or steering the subject away from your point, just tell me to delete my posts and i will do.

[Attila Kovacs 631]

I'm using A and O. And I can write it down by my own.