Sometimes Para prefix before Parameters can be more clear.

[Skybuck]

Another similiar coding tip:

Use Para before every parameter, example:

procedure MyRoutine( ParaSomeVariable : integer );
begin
ParaSomeVariable := 12345;
end;

This will make it more clear inside the code of the routine that "SomeVariable" is actually a parameter and not a local variable and not a self/object field or member, and not other field from a with statement or some unit variable, etc.

[Skybuck]

" HermanSchoenfeld commented a day ago Please join Discord and discuss there."

I have discussed some issues with you before and you ended up deleting some of my discussions which is a waste of time for me.

The tips I have given on github/pascalcoin are practices from my 20 years of experience with Delphi development and are true and tried ways of code development.

These tips in technical terms make the scope of variables much more clear, something I once saw a noobie Delphi programmer struggle with which was and still is somewhat amuzing, but a valid observation by a noobie: "Where do these (object) variables come from ?".

Anyway the question is if you guys want to write top code or below average code for a "given horse". I can understand a "given horse", though a/this coin system is so much fun it deserves a bit better =D

Every adventage has disadventages though, it does require some more letters to be typed and I can understand Albert Molina for example may have very little time and want to write some short code and so forth, I am a bit surprised the code works as good as it does, since shorter notations are more prone and should have led to some more hard to find bugs, perhaps there still are somewhat but these are probably more related to design of code, then naming of variables/fields and so forth.

I did notice some mis alignments of begin/end statement blocks, these could lead to bugs someday when code new code is added, though I doubt this will happen cause the programmer involved will probably check statement blocks begin/end alignment anyway when written new code, though if code is written a bit more lazy there is a chance a bug might be introduced which could have been avoided.

There are other reasons to "update/refactor" the code:

    Make it look more professional.

Currently it's not looking very professional. Any skilled Delphi programmer can immediately see that 1 or 2 letter local variable names are not state of the art or "high quality code" and might be put off by it. I kinda wonder how serious other people/programmer take this project when they look at the code, this might have some impact on how this project is perceived.

If the code is not clear it might also hamper usage of it in other projects. I think more focus should be added to trying to reduce complexity of code, making it more understandable and perhaps even splitting it up into multiple settings or packages/dlls for binary re-use by other projects, (instead of adding new features upon features upon features, it's probably a matter of time before the project runs into some technical problem or limitation, though I hope this does not happen and perhaps the lack of proper structuring might even make it easier to add some more code to it, but who then is going to follow and use this project if it's code keeps changing in all kinds of unpredictable ways. This could be a reason to prevent new features for example 1 year or 2 years, so that others might be able to use a "stable project" where there is only focus on bug fixes and code improvements (which is a bit contrary to what I wrote before about being stable). Though some code improvements are probably easier to deal with then constantly changing and new features. Perhaps the release cycle wasn't that big...

Protocol versions v1, v2, v3 and now v4 is coming in what ? 2 years ? That's a lot of protocol versions in just 2 years. How long did internet last with just ipv4 ?

Can you imagine if internet ipv4 changed every 6 months ? Hmmm....

I like to see new features and see what you guys are capable of, but it does come at a price, I hope you are all aware of that to some degree

Also "applications" on top of a protocol, is that really what users want ? Or do they just want to exchange "virtual money" ? I think probably the latter, if not I would probably be drooling all over ethereum or something similiar

(My funny joke for you is: Discord is more like Discard =D)

[Skybuck]

 dslutej commented 2 days ago

procedure MyRoutine( ASomeVariable : integer );
begin
ASomeVariable := 12345;
end;

Isn't this standard in Delphi tho'? A-prefix for parameters where needed (particularly methods, not so much classic functions/parameters).

Para-prefix waaaay too long imho.

[Skybuck]

I think I have seen this before at some places, but it is rare. What does the letter A stand for ? It should have some meaning otherwise it's pretty arbitrary and might some day confuse somebody

I do agree Para is a bit long, but it's better than nothing pSomeVariable would be too confusing because most will probably assume p means pointer, so that's why I would go for Para.

Though parameter does contain two a's so I can see a little bit why A would be chosen. It might still be possible for a programmer who looks at code:

ASomeVariable := 12345; To assume it's just "some variable" probably a local variable... so doesn't make it that much more clear, it kinda also looks a bit like a member variable where using Capital letter F is common.

FSomeField
FSomeMember

Starting with A/O/E/U is also somewhat unusual.

What is kind of important here is that when the code is read out loud that it makes some sense, if it's hard or akward or cryptic then that is a bad sign.