Format Code before save automatically

[aag031]

Dear All
Is there possibility formatting code  automatically before saving?

From other hands

Is there possibility when user clicks save button code is formatted then saved
I did not find this possibility in options configuration.
I've started to use Lazarus recently, may be I missed something


WBR
Alexander

[AlexTP]

Seems no 'on save'. But you can call IDE menu "Souce / Jedi code format" menu to run it.

[Zvoni]

I have no idea why someone would need such a feature.....

[Sniper]

I have no idea why someone would need such a feature.....

If you works in a team then you definitely have to follow for style guides.

[af0815]

I have no idea why someone would need such a feature.....

If you works in a team then you definitely have to follow for style guides.

But then you have it to use _before_ save. Because ia team you use normal a Sourcecontrol tool and it is not good, automatic styles are automatic added on code. It confuses the diffs. It is hard enough with lineendings on the the three platforms and GIT.

[Sniper]

I have no idea why someone would need such a feature.....

If you works in a team then you definitely have to follow for style guides.

But then you have it to use _before_ save. Because ia team you use normal a Sourcecontrol tool and it is not good, automatic styles are automatic added on code. It confuses the diffs. It is hard enough with lineendings on the the three platforms and GIT.

Git has an option how to deal with line endings.

Ok, Python, Go has numerous utils to lint (mypy, pylint.. ) and format (gofmt..) the code before save. This is a cool feature for development in big teams isnt it? As 2022 language Freepascal must have this type of "sugar" too. Am I wrong?

[marcov]

Automated formatting in pascal is not an new phenomenon, and also the difference in opinion is quite an old fight, I can remember it already having it in the early 2000s. It is by no means something modern.

In Lazarus circles it is not very popular, and in Delphi circles only slightly more. Usually in such cases formatters are run in the post commit hook of the VCS.

I never cared much for it. The benefits are doubtful, and only triggers eternal discussion about what should be the right style right down to the extremely trivial. All that time micromanaging  is better spent elsewhere.

[af0815]

This is no new discussion about sugar (its more salt). I know this dicussion back to the M80/L80/Cref80 times on CP/M. And later TP on this platform. 

Yes you are wrong. I is the same old discussion like other.

[440bx]

This is a cool feature for development in big teams isnt it? As 2022 language Freepascal must have this type of "sugar" too. Am I wrong?

I strongly believe in the value of properly formatted code.  When properly formatted, the code is easier to understand and easier to maintain.

That said, as others above have already mentioned, code formatting seems to vary significantly from programmer to programmer and, opinions about what the format should be, even more.

My personal opinion is that a programmer should format the code as he/she is programming.  That should be instinctive and automatic thus making code formatters utilities of questionable value because, if the programmer can't figure out how to format code or not take the minimal amount of time it takes to format code then, that's quite likely not code I want to read (formatted or otherwise.)

[PascalDragon]

Ok, Python, Go has numerous utils to lint (mypy, pylint.. ) and format (gofmt..) the code before save. This is a cool feature for development in big teams isnt it? As 2022 language Freepascal must have this type of "sugar" too. Am I wrong?

Lazarus has the Jedi Code Formatter and there's also the command line utility ptop. I'm sure someone would be able to hook them up to the IDE in a way they can be triggered upon safe (JCF can already be triggered with an explicit key sequence if installed). Or at least the latter could be used as part of a commit hook or whatever. So everything that's needed is there (though both components might struggle with some language features).