Mike Torrettinni

Excellent! I don't use threads often, but can't wait to try it out! Great job @Dave Millington (personal)! 🙂

I completely agree with you, that's why I hope CE is coming back with 10.5 and will be released with every single version. This should be long term plan, not important to yearly sales reports on conversion.

I think 10.5 will be next CE edition, but not 100%. They are disappointed in lack of conversion from CE to full (paid) version. What feature are you looking for in 10.4.1 that is not in 10.3? I'm still on 10.2.3.

Thanks, pretty interesting topic!

@Remy Lebeau May I ask why did you decide not to use in released software, did you have any user feedback on the feature and you decided not to include it, or the feature was never meant to be for released version?

Wow, I didn't know these animations broke out of Microsoft tools into the wild. Pretty bold to implement this into Delphi project. People were complaining when Ribbon started appearing in software, I can't imagine what same people would say when a clip, monkey or a butler shows up on a screen and start 'helping' 🙂 I do customize my software to some extent to what I like, but this is way out there for me - and that's why it's very interesting 🙂 So, I'm very interested in your feedback how it turned out to be, how your users reacted to it. If you want update this thread in a couple of weeks or months, please do.

It's interesting that A is used for parameter definition and not P. If you go through Delphi's units, you can find very consistent inconsistency in parameter prefixes: // parameters (const AContext: TObject) (const AsyncResult: TBaseAsyncResult) (const Waiter: TWaitInfo) (const Ref: Pointer; ATypeInfo: PTypeInfo) (const AArray: Pointer; ATypeInfo: PTypeInfo) same for method vars: // no prefix var Instances: TDictionary<Pointer, Integer>; ReferenceStack: TStack<IntPtr>; // prefix var LList: IInterfaceList; LControlValueObserver: IControlValueObserver; LTrack: IObserverTrack; // mixed :-) var I: Integer; LPreamble: TBytes; BOMPresent: Boolean; I guess I'm making too much out of all these prefixes 🙂

Wow, I never heard of kebab-case before this topic. Interesting how many new things you find out about a simple thing like naming, prefixes and styles in programming 🙂

Aha, thanks, it's clear now. Local unit vars and local method vars, I guess I chose x prefix for local unit vars because they are rare and is important to know the scope(visibility?), like you pointed out: interface type TMyClass = class private fValue: integer; end; const cMyConst = 1; var gGlobalVar: integer; implementation type TMyLocalUnitType = integer; var xLocalUnitVar: integer; procedure A(aParam: integer); var vLocalMethodVar: integer; begin xLocalUnitVar := vLocalMethodVar + aParam; end;

Not sure what you are asking me here.

I kind of got used to assigning prefixes to differentiate between them. Also, for this topic I refer to parameters and class field also variables. You don't prefix any variables?

Yes, these are the local variables, defined in implementation section. I rarely use them, but still do sometimes. I used to use them a lot, just like global vars, until I learned better. I only use them for local methods. But as soon as it makes sense I create a class and it becomes a field. In those rare occasions you do specify them, do you use a prefix for them? L, l, x?

And that's pretty cool. Can you imagine being forced to use the one you don't really like? But I guess you get used to anyone, eventually.

I don't get it... too many styles? Everybody can find a style they like 🙂

Wow, how many different styles/case types - KebabCase wins the name 😛 ALL CAPS BiCapitalized BumpyCase CamelCase CanonicalStudlyCaps Capitalization EmbeddedUnderscore German case HumpBackNotation InfixCaps InterCaps KebabCase 🐑🍽️ Leet lowerCamelCase Mixed case MixedCase NerdCaps PascalCase Sentence case SMALL CAPS SNAKE_CASE StickyCaps StudlyCaps Title case UpperCamelCase UpperCase with hyphens WikiCase

🙂 Ego <> smart!

There are a few older threads that many git tools were suggested and compared:

Someone must have felt really good writing this statement: Delphi is created in California, so we discourage the use of hungarian notation, except where required in header translations ... 🙂 (in https://wiki.delphi-jedi.org/wiki/Project_JEDI_Delphi_Language_Style_Guide) There's actually an SO question about it: https://stackoverflow.com/questions/18583756/what-is-meant-by-delphi-is-created-in-california-so-we-discourage-the-use-of-n 🙂 🙂 Seems like everybody coming up with their own naming conventions are really proud of their work. Which is pretty cool as many developers rely on their set of rules. I had no idea this was such a big and important topic in Delphi! 🙂

I totally agree with you! Such a small thing ad makes a big difference. Except for type TType, I still use T for all types. Not sure why, but probably has something to do with the fact that it start the line/name. type TProject = ... tProject = .... lower t just seems off in this case. 🙂

Interesting, I never noticed that, usually is A, or no prefix. I did notice a few a prefix examples, but not many. I just checked some open source projects that I look at at time to time and I do see this, but is again capital V like : var VUserName. Capital prefixes seem so old-school.

I never liked Hungarian style, perhaps I would like it in 1972, but I wasn't born then, yet. I used to try with prefixing variables by type - no way! 🙂 I use GExpert's Align lines to align assignments ( :=, =,<> ) when in multiple consecutive lines,

That's interesting. I used to prefix fFunction and pProcedure, but I stopped as I figured out it doesn't matter to know from the name if it's function or procedure, so these have no prefixes anymore.

Aha, yes correct, thanks! I just couldn't deal with AArgName/AParamName, these capital prefixes look so out of place - I know it's personal preference, but I'm usually the only developer, so I have a little more wiggle room with namings.

So, now we have: // overloaded Ifthen i := IfThen(cond, 1, 2); // namespaced overloaded i := ProjectName.Utilities.IfThen(cond, 1, 2); // class i := Generic.IfThen<integer>(cond, 1, 2); // namespaced class i := ProjectName.Utilities.Generic.IfThen<integer<(cond, 1, 2); // record i := Conditional<integer>.When(cond, 1, 2); // namespaced record i := ProjectName.Utilities.Conditional<integer>.When(cond, 1, 2); Any more?

OK, thanks! The difference is because of it's record and not a class, right? Record is <T> type while class has a method of <T> type.