Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2018-03

Fix CamelCase in unit and method names

18 messages · 11 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Ondrej Pokorny

Hello,

will a patch be applied that fixes CamelCase in unit and method names and other identifiers?

Example:

dateutils -> DateUtils
sysutils -> SysUtils
typinfo -> TypInfo
contnrs -> Contnrs
strutils -> StrUtils
EnterCriticalsection -> EnterCriticalSection
DoneCriticalsection -> DoneCriticalSection
LeaveCriticalsection -> LeaveCriticalSection
TryEnterCriticalsection -> TryEnterCriticalSection (Funnily enough InitCriticalSection is correct.)

TPoint.x -> TPoint.X
TPoint.y -> TPoint.Y

(For unit names: of course only the unit definition name will be changed, not the file name).

Ondrej

Reply by email

Michael Van Canneyt
to Ondrej Pokorny
Ondrej Pokorny wrote 23 lines
Hello, will a patch be applied that fixes CamelCase in unit and method names and other identifiers? Example: dateutils -> DateUtils sysutils -> SysUtils typinfo -> TypInfo contnrs -> Contnrs strutils -> StrUtils EnterCriticalsection -> EnterCriticalSection DoneCriticalsection -> DoneCriticalSection LeaveCriticalsection -> LeaveCriticalSection TryEnterCriticalsection -> TryEnterCriticalSection (Funnily enough InitCriticalSection is correct.) TPoint.x -> TPoint.X TPoint.y -> TPoint.Y (For unit names: of course only the unit definition name will be changed, not the file name).

At first sight I don't see any disadvantages from this, so yes, I would apply such a patch.

Code completion will benefit from it, I suppose.

Michael.

Reply by email

Tomas Hajny
to Michael Van Canneyt
Michael Van Canneyt wrote
On Thu, 22 Mar 2018, Ondrej Pokorny wrote:

Hi,

Show quoted text 10 lines
> will a patch be applied that fixes CamelCase in unit and method names > and other identifiers? > > Example: > > dateutils -> DateUtils > sysutils -> SysUtils > typinfo -> TypInfo > contnrs -> Contnrs > strutils -> StrUtils

.
.

Show quoted text 5 lines
> (For unit names: of course only the unit definition name will be > changed, not the file name). At first sight I don't see any disadvantages from this, so yes, I would apply such a patch.

IMHO preferably not the unit names (as in 'unit XxX') - with case sensitive file names on Unix, this change might increase time for searching the respective file (somewhat). Obviously, all further references of the unit (as in 'SysUtils.Execute') should be fine.

Tomas

Reply by email

Michael Van Canneyt
to Tomas Hajny
Tomas Hajny wrote 28 lines
On Thu, March 22, 2018 12:42, Michael Van Canneyt wrote: > On Thu, 22 Mar 2018, Ondrej Pokorny wrote: Hi, >> will a patch be applied that fixes CamelCase in unit and method names >> and other identifiers? >> >> Example: >> >> dateutils -> DateUtils >> sysutils -> SysUtils >> typinfo -> TypInfo >> contnrs -> Contnrs >> strutils -> StrUtils . . >> (For unit names: of course only the unit definition name will be >> changed, not the file name). > > At first sight I don't see any disadvantages from this, so yes, I would > apply such a patch. IMHO preferably not the unit names (as in 'unit XxX') - with case sensitive file names on Unix, this change might increase time for searching the respective file (somewhat). Obviously, all further references of the unit (as in 'SysUtils.Execute') should be fine.

But only if it is in a uses clause, not the actual unit xx; clause ?

Michael.

Reply by email

Denis Kozlov
to Ondrej Pokorny: will a patch be applied that fixes CamelCase in unit and method names and other…

Please do... It has caused enough eye (OCD) stress over the years ;)

Denis

Ondrej Pokorny wrote 29 lines
Hello, will a patch be applied that fixes CamelCase in unit and method names and other identifiers? Example: dateutils -> DateUtils sysutils -> SysUtils typinfo -> TypInfo contnrs -> Contnrs strutils -> StrUtils EnterCriticalsection -> EnterCriticalSection DoneCriticalsection -> DoneCriticalSection LeaveCriticalsection -> LeaveCriticalSection TryEnterCriticalsection -> TryEnterCriticalSection (Funnily enough InitCriticalSection is correct.) TPoint.x -> TPoint.X TPoint.y -> TPoint.Y (For unit names: of course only the unit definition name will be changed, not the file name). Ondrej _______________________________________________ fpc-devel maillist  -  http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Reply by email

R0b0t1
to Tomas Hajny: . . IMHO preferably not the unit names (as in 'unit XxX') - with case sensitive file…
Michael Van Canneyt wrote 34 lines
On Thu, 22 Mar 2018, Ondrej Pokorny wrote: > Hello, > > will a patch be applied that fixes CamelCase in unit and method names and > other identifiers? > > Example: > > dateutils -> DateUtils > sysutils -> SysUtils > typinfo -> TypInfo > contnrs -> Contnrs > strutils -> StrUtils > EnterCriticalsection -> EnterCriticalSection > DoneCriticalsection -> DoneCriticalSection > LeaveCriticalsection -> LeaveCriticalSection > TryEnterCriticalsection -> TryEnterCriticalSection > (Funnily enough InitCriticalSection is correct.) > > TPoint.x -> TPoint.X > TPoint.y -> TPoint.Y > > (For unit names: of course only the unit definition name will be changed, > not the file name). At first sight I don't see any disadvantages from this, so yes, I would apply such a patch. Code completion will benefit from it, I suppose.

I asked about this a while ago; please apply the patches if any are made.

Tomas Hajny wrote 29 lines
On Thu, March 22, 2018 12:42, Michael Van Canneyt wrote: > On Thu, 22 Mar 2018, Ondrej Pokorny wrote: Hi, >> will a patch be applied that fixes CamelCase in unit and method names >> and other identifiers? >> >> Example: >> >> dateutils -> DateUtils >> sysutils -> SysUtils >> typinfo -> TypInfo >> contnrs -> Contnrs >> strutils -> StrUtils . . >> (For unit names: of course only the unit definition name will be >> changed, not the file name). > > At first sight I don't see any disadvantages from this, so yes, I would > apply such a patch. IMHO preferably not the unit names (as in 'unit XxX') - with case sensitive file names on Unix, this change might increase time for searching the respective file (somewhat). Obviously, all further references of the unit (as in 'SysUtils.Execute') should be fine.

I don't understand how it would increase the search time. I believe what happens is all names are converted to lowercase for the search, as in the strings taken from the user or their files and the names taken from the disk are both converted to lower case before comparisons are made.

This is why some of the unit names are entirely lower case - they were at some point stored internally as entirely lower case, and no one fixed them (because you have to do it each time you interact with certain IDE GUIs). There may have been some versions of Lazarus that would not allow you to save mixed case file names, or at least made it very hard to do so.

I suspect some of the mixed case file names that are not capitalized properly are due to the lack of case sensitivity and code completion. I found some Microsoft projects which misspelled something the same way in each of 4-5 places, probably because the name was typed once and then never fully typed again.

Following from the above, very interesting patches would be ones that do not automatically lower case file names in Lazarus.

Cheers,
R0b0t1

Reply by email

R0b0t1
to Juha Manninen
Juha Manninen wrote 9 lines
On Thu, Mar 22, 2018 at 3:15 PM, Denis Kozlov wrote: > Please do... It has caused enough eye (OCD) stress over the years ;) +1 Yes, it has bothered also me a lot. I use code completion to get the unit names correctly. Most of them are CamelCase but some are lowercase. The result looks sloppy. Maybe it is OCD, don't know. It bothers me anyway.

I agree it looks sloppy. Something else that has bothered me, but a lot less, is the conflicting naming standards.

E.g. Contnrs "should" really be Containers, more like Delphi; the former is more of a C style that you find when everything is lower case and abbreviated, which is not really the style I see most Object Pascal programmers adopt.

I apologize for the unwarranted opinion, but it had been bothering me for a while.

Cheers,
R0b0t1

Reply by email

Anthony Walter
to Juha Manninen: +1 Yes, it has bothered also me a lot. I use code completion to get the unit names…

Yes, I agree, both for unit names, but also for methods and arguments. The exceptions should be for code related that are imports or extensions of existing APIs, for example:

cairo_create should remain the same
glGenBuffers should remain the same
gtk_window_new should remain the same
dlopen should remain the same

But in the RTL or LCL here are some of many pure pascal functions or procedures that could have their case changed:

abs should be Abs
arctan should be ArcTan
getdir should be GetDir
intpower should be IntPower
hexstr should be HexStr
strcan should be StrScan

And with RTL or LCL unit names:

keyboard should be Keyboard
math should be Math
strutils should be StrUtils
cthreads should be CThreads

Same applies to function/procedure/method arguments. If they're a pure pascal original, then arguments should be CamelCase. If they are part of an API imported, then they should remain the way the original API declares them.

IMO

Reply by email

Mark Morgan Lloyd
to Juha Manninen: +1 Yes, it has bothered also me a lot. I use code completion to get the unit names…
Juha Manninen wrote
On Thu, Mar 22, 2018 at 3:15 PM, Denis Kozlov wrote:> Please do... It has caused enough eye (OCD) stress over the years ;) +1Yes, it has bothered also me a lot. I use code completion to get theunit names correctly. Most of them are CamelCase but some arelowercase. The result looks sloppy. Maybe it is OCD, don't know. Itbothers me anyway.

Is my understanding correct that there's no compiler warning for this sort of inconsistency?

Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]

Reply by email

Paul Michell
to Anthony Walter: Yes, I agree, both for unit names, but also for methods and arguments. The exceptions…
Anthony Walter wrote 33 lines
Yes, I agree, both for unit names, but also for methods and arguments. The exceptions should be for code related that are imports or extensions of existing APIs, for example: cairo_create should remain the same glGenBuffersshould remain the same gtk_window_newshould remain the same dlopenshould remain the same But in the RTL or LCL here are some of many pure pascal functions or procedures that could have their case changed: abs should be Abs arctanshould be ArcTan getdirshould be GetDir intpower should be IntPower hexstr should be HexStr strcan should be StrScan And with RTL or LCL unit names: keyboard should be Keyboard math should be Math strutils should be StrUtils cthreads should be CThreads Same applies to function/procedure/method arguments. If they're a pure pascal original, then arguments should be CamelCase. If they are part of an API imported, then they should remain the way the original API declares them. IMO

I agree, pure Pascal should use CamelCase, otherwise we should follow the published API.  In all cases usage should follow the declaration. I must have the same OCD variant too!

Reply by email

Sven Barth
to Mark Morgan Lloyd: Is my understanding correct that there's no compiler warning for this sort of…

Mark Morgan Lloyd schrieb am Do., 22.
März 2018, 17:57:

Show quoted text 10 lines
On 22/03/18 15:30, Juha Manninen wrote: > On Thu, Mar 22, 2018 at 3:15 PM, Denis Kozlov wrote:> Please do... It has caused enough eye (OCD) stress over the years ;) > +1Yes, it has bothered also me a lot. I use code completion to get theunit names correctly. Most of them are CamelCase but some arelowercase. The result looks sloppy. Maybe it is OCD, don't know. Itbothers me anyway. Is my understanding correct that there's no compiler warning for this sort of inconsistency?

Of course there isn't. After all Pascal is case insensitive, so everyone is free to case the identifiers as they want.

Regards,
Sven

Reply by email

Michael Van Canneyt
to R0b0t1: On Thu, Mar 22, 2018 at 10:18 AM, Juha Manninen I agree it looks sloppy. Something else…
R0b0t1 wrote 16 lines
On Thu, Mar 22, 2018 at 10:18 AM, Juha Manninen wrote: > On Thu, Mar 22, 2018 at 3:15 PM, Denis Kozlov wrote: >> Please do... It has caused enough eye (OCD) stress over the years ;) > > +1 > Yes, it has bothered also me a lot. I use code completion to get the > unit names correctly. Most of them are CamelCase but some are > lowercase. The result looks sloppy. Maybe it is OCD, don't know. It > bothers me anyway. > I agree it looks sloppy. Something else that has bothered me, but a lot less, is the conflicting naming standards. E.g. Contnrs "should" really be Containers, more like Delphi;

It's called contnrs in delphi as well.
You're probably confusing the classes based one with the generic based one.

Michael.

Reply by email

Sven Barth
to R0b0t1: On Thu, Mar 22, 2018 at 6:42 AM, Michael Van Canneyt I asked about this a while ago;…

R0b0t1 schrieb am Fr., 23. März 2018, 16:07:

Show quoted text 13 lines
> > IMHO preferably not the unit names (as in 'unit XxX') - with case > sensitive file names on Unix, this change might increase time for > searching the respective file (somewhat). Obviously, all further > references of the unit (as in 'SysUtils.Execute') should be fine. > I don't understand how it would increase the search time. I believe what happens is all names are converted to lowercase for the search, as in the strings taken from the user or their files and the names taken from the disk are both converted to lower case before comparisons are made.

FPC first looks for the unit with the name as is, then lower case and finally upper case.

Regards,
Sven

Reply by email

Michael Van Canneyt
to Sven Barth
Sven Barth wrote 18 lines
R0b0t1 schrieb am Fr., 23. März 2018, 16:07: >> >> IMHO preferably not the unit names (as in 'unit XxX') - with case >> sensitive file names on Unix, this change might increase time for >> searching the respective file (somewhat). Obviously, all further >> references of the unit (as in 'SysUtils.Execute') should be fine. >> > > I don't understand how it would increase the search time. I believe > what happens is all names are converted to lowercase for the search, > as in the strings taken from the user or their files and the names > taken from the disk are both converted to lower case before > comparisons are made. > FPC first looks for the unit with the name as is, then lower case and finally upper case.

Yes, but this is done in memory in the directory cache.

I tested make all, there is no discernable difference in time, so I applied the patch from Ondrej.

Michael.

Reply by email

Pierre Muller
to Michael Van Canneyt

Le 23/03/2018 à 23:12, Michael Van Canneyt a écrit :

Show quoted text 24 lines
On Fri, 23 Mar 2018, Sven Barth via fpc-devel wrote: > R0b0t1 schrieb am Fr., 23. März 2018, 16:07: > >>> >>> IMHO preferably not the unit names (as in 'unit XxX') - with case >>> sensitive file names on Unix, this change might increase time for >>> searching the respective file (somewhat). Obviously, all further >>> references of the unit (as in 'SysUtils.Execute') should be fine. >>> >> >> I don't understand how it would increase the search time. I believe >> what happens is all names are converted to lowercase for the search, >> as in the strings taken from the user or their files and the names >> taken from the disk are both converted to lower case before >> comparisons are made. >> > > FPC first looks for the unit with the name as is, then lower case and > finally upper case. Yes, but this is done in memory in the directory cache.

But isn't the problem more that if you have a SysUtils.pp unit and a sysutils.pp both in your unit search path,
on a case sensitive partition, it might now find SysUtils.pp before sysutils.pp and end up with some total different source?

Pierre Muller

Reply by email

Michael Van Canneyt
to Pierre Muller
Pierre Muller wrote 32 lines
Le 23/03/2018 à 23:12, Michael Van Canneyt a écrit : > > > On Fri, 23 Mar 2018, Sven Barth via fpc-devel wrote: > >> R0b0t1 schrieb am Fr., 23. März 2018, 16:07: >> >>>> >>>> IMHO preferably not the unit names (as in 'unit XxX') - with case >>>> sensitive file names on Unix, this change might increase time for >>>> searching the respective file (somewhat). Obviously, all further >>>> references of the unit (as in 'SysUtils.Execute') should be fine. >>>> >>> >>> I don't understand how it would increase the search time. I believe >>> what happens is all names are converted to lowercase for the search, >>> as in the strings taken from the user or their files and the names >>> taken from the disk are both converted to lower case before >>> comparisons are made. >>> >> >> FPC first looks for the unit with the name as is, then lower case and >> finally upper case. > > Yes, but this is done in memory in the directory cache. But isn't the problem more that if you have a SysUtils.pp unit and a sysutils.pp both in your unit search path, on a case sensitive partition, it might now find SysUtils.pp before sysutils.pp and end up with some total different source?

No, since the names of the files are not changed, and the names of the units in the uses clauses are not changed, and those are the ones that matter when searching, not the ones in the unit xyz; statement.

And if you have this situation on your hard disk, you deserve to be publicly flogged, covered in tar and feathers, and banished from your village forever.

Michael.

Reply by email