Re: Mono-D v0.4.9 - Rough formatting capability
On Monday, 21 January 2013 at 21:35:11 UTC, alex wrote: On Monday, 21 January 2013 at 21:32:38 UTC, F i L wrote: Thanks Alex, even though I don't use auto-formatting (I never did like that). I use it rarely either - but some others asked whether I could do this - and now there it is :) Lack of auto-formatter was the reason I stopped using Mono-D some time ago :) Awesome update, good luck with this!
Re: Mono-D v0.4.9 - Rough formatting capability
On Tuesday, 22 January 2013 at 10:26:21 UTC, mist wrote: On Monday, 21 January 2013 at 21:35:11 UTC, alex wrote: On Monday, 21 January 2013 at 21:32:38 UTC, F i L wrote: Thanks Alex, even though I don't use auto-formatting (I never did like that). I use it rarely either - but some others asked whether I could do this - and now there it is :) Lack of auto-formatter was the reason I stopped using Mono-D some time ago :) Awesome update, good luck with this! Uhm..what is an auto-formatter in your eyes? Automatic formatting when you typed a '}' for instance? Or just the explicit possibility to let a program format your code? I mean, once the code got indented correctly, why should it ever be passed through a formatter again? Just to see that it's actually been indented correctly? Hmm..
Re: Mono-D v0.4.9 - Rough formatting capability
I always define project code style policies in Eclipse code style settings and run auto-format (Ctrl+Shift+F) on new code always before commiting to ensure my nasty personal preferences have not slipped out of subconscious. It also converts all whitespaces consistently to match project settings and sometimes I forget to setup tab->space autoreplacement for external editors. In-place formatting is not that important for me. On Tuesday, 22 January 2013 at 14:44:15 UTC, alex wrote: On Tuesday, 22 January 2013 at 10:26:21 UTC, mist wrote: On Monday, 21 January 2013 at 21:35:11 UTC, alex wrote: On Monday, 21 January 2013 at 21:32:38 UTC, F i L wrote: Thanks Alex, even though I don't use auto-formatting (I never did like that). I use it rarely either - but some others asked whether I could do this - and now there it is :) Lack of auto-formatter was the reason I stopped using Mono-D some time ago :) Awesome update, good luck with this! Uhm..what is an auto-formatter in your eyes? Automatic formatting when you typed a '}' for instance? Or just the explicit possibility to let a program format your code? I mean, once the code got indented correctly, why should it ever be passed through a formatter again? Just to see that it's actually been indented correctly? Hmm..
Re: Mono-D v0.4.9 - Rough formatting capability
On Tuesday, 22 January 2013 at 15:54:46 UTC, mist wrote: I always define project code style policies in Eclipse code style settings and run auto-format (Ctrl+Shift+F) on new code always before commiting to ensure my nasty personal preferences have not slipped out of subconscious. It also converts all whitespaces consistently to match project settings and sometimes I forget to setup tab->space autoreplacement for external editors. In-place formatting is not that important for me. So that's the exact thing I'm trying to implement: To define an IDE- or project-wide formatting policy and let this control the code style. Let's see how far I can do it :)
Re: A look at the D programming language by Ferdynand Górski
On Tuesday, 22 January 2013 at 03:00:59 UTC, deadalnix wrote: The sane option are either to acknowledge that code is in a text file and choose syntax construct that make it readable (python) or decorrelate the presentation of the code from its actual form in the file and use a formatted. Out of the two options, I would say that the correctness of the source should not be dependent on how it is formatted. One advantage of this, is that you can compact the source by removing all unnecessary white space and line returns. Another reason is that source code can be automatically generated without the costly complication of having to correctly format it. Compacted source code works well for transmission over a network and for storage in a database. Sure, speeds are high and storage is cheap, but if you consider something like javascript, there's an overall huge amount of continual resource waste when needlessly formatted code is transmitted, interpreted, and stored. This is why JS code is usually compacted when it goes into a release state. --rt
