Re: indent style for D
On Sun, 29 Jan 2012 21:20:01 +0100, Timon Gehr wrote: > On 01/29/2012 08:26 PM, Marco Leise wrote: >> Am 29.01.2012, 16:23 Uhr, schrieb Trass3r : >> Am I mistaken? If no, am I missing some major spaces advantages? If no, lets use tabs. Perhaps, there is no tool that will convert (convert right, not somehow, see article) tabs<->spaces in D code. >>> >>> There wouldn't be any problem if people were able to use tabs for >>> indentation and spaces for alignment, i.e. in cases like if (cond1 && >>> cond2) >>> >>> But people are dumb and many project leaders "take no risks" and >>> require spaces everywhere instead of doing it properly. >> >> If it cheers you up, I use that style. Once you get used to 'smart >> tabs' it is like using spaces. Just now and then I catch myself using >> tabs on the alignment for local variable comments: >> >> int foo; // does something (tabs) >> int bar; // something else (spaces) >> >> Then again "tabs for indentation only" is a simple rule, that would >> have turned the tabs into spaces in this example - if editors supported >> it. > > *Real* editors can be configured to support smart tabs. So a butterfly. -- Yep, I'm afraid that I have a blog : zardoz.es
Re: indent style for D
On Tue, Jan 31, 2012 at 02:43:57AM +, Stewart Gordon wrote: > On 30/01/2012 02:24, H. S. Teoh wrote: > > >And I'd love to have my integer set class > >be able to use ∪ and ∩ instead of verbose operations like x.union(y) and > >x.intersection(y). > > > My utility library uses | and &. Think of the possible values of the > type you're creating a set of as being like the bits of a number, and > then it makes sense. [...] Funny you should mention that; my integer set class represents set members as bits, and set operations are implemented as bitwise operations. :) Still, though, it'd be nice to have actual set notation. But I was only being half-serious. T -- BREAKFAST.COM halted...Cereal Port Not Responding. -- YHL
Re: indent style for D
On 30/01/2012 02:24, H. S. Teoh wrote: And I'd love to have my integer set class be able to use ∪ and ∩ instead of verbose operations like x.union(y) and x.intersection(y). My utility library uses | and &. Think of the possible values of the type you're creating a set of as being like the bits of a number, and then it makes sense. Stewart.
Re: indent style for D
On Monday, 30 January 2012 at 10:16:36 UTC, Denis Shelomovskij wrote: I started this thread Poor topicstarter. His topic is hijacked and buried if flame, and he himself is sent to oblivion.
Re: indent style for D
On 1/30/2012 2:16 AM, Denis Shelomovskij wrote: P.S. I started this thread because of wasting my time for conversion/checking and inconsistent situation: druntime/Phobos have both spaces/tabs now (yes, there are significantly more spaces, but it doesn't reduce the problem), e.g. you just broke formatting in std/stream.d: https://github.com/D-Programming-Language/phobos/commit/f3aa58592faed9a418e347090cd614670947fef4 Problems crop up when people check in stuff with tabs in it. I run everything I check in through detab.
Re: indent style for D
30.01.2012 0:49, Walter Bright пишет: On 1/29/2012 6:04 AM, Denis Shelomovskij wrote: Why does Phobos use 4-space indentation? Because it works, changing it would be a vast waste of time for a non-existent benefit, and it would become a nuisance to do diffs of source code that cross the re-whitespace boundary. The style for Phobos is 4 space indentation, no tab characters anywhere, and LF line endings (to make github happy). OK, the major advantage of spaces is because my approach (tabs for indention, spaces for alignment) isn't testable by a tool that doesn't know D semantics. More than that, my approach isn't a full solution too. It's outdated like spaces because of elastic tabstops. By the way, elastic tabstops looks easy auto-testable too so once we will just migrate to it (I hope). But the current situation is still unpleasant because: * There are no suggestions of using some tools for developers to automate conversion, so there is already a wasting of our time (developers and commit reviewers/mergers). * Look's like nobody ever tested Phobos files for tabs. P.S. I started this thread because of wasting my time for conversion/checking and inconsistent situation: druntime/Phobos have both spaces/tabs now (yes, there are significantly more spaces, but it doesn't reduce the problem), e.g. you just broke formatting in std/stream.d: https://github.com/D-Programming-Language/phobos/commit/f3aa58592faed9a418e347090cd614670947fef4
Re: indent style for D
On 01/29/2012 02:27 PM, H. S. Teoh wrote: >> Why do so many programmers hanker for the 1960s and the necessity of >> monospace fonts, it seems irrational. > > I am irrational. > > ;-) Proudly, me too! I want to look at monospaced code with to tabs anywhere in it; and since I like what came out of the 1960s, 80 columns for me! :) Ali
Re: indent style for D
On Monday, 30 January 2012 at 01:45:40 UTC, Walter Bright wrote: On 1/29/2012 2:41 PM, Kagamin wrote: On Sunday, 29 January 2012 at 20:53:51 UTC, Walter Bright wrote: tolf AFAIK, only windows notepad can't handle lf nowadays. That's it? So far, I've seen no issues with standardizing on LF line endings. Ermm... I mean, if you use tolf, then your editor uses something else? I guessed what is this editor.
Re: indent style for D
On Mon, Jan 30, 2012 at 03:35:03AM +, Iain Buclaw wrote: > On 30 January 2012 03:27, H. S. Teoh wrote: > > On Mon, Jan 30, 2012 at 01:57:43AM +0100, Timon Gehr wrote: [...] > >> - And when saving, it automatically formats the source code in the > >> deduced format. > > > > The problem with autoformatting on save is that it interacts badly > > with revision control systems. You could end up with lots of noisy > > diffs mostly involving changes in whitespace. By enforcing a fixed > > formatting, whether it's everything-on-a-line or delete all > > unnecessary whitespace but leave newlines intact, you ensure that > > diffs generated by the revision control system will not include > > whitespace noise. > > > > The flip side is that if you put everything on one line, no one will > be able to understand the commits you make. :) [...] Well, that's no fault of mine; it's a relic of holding on to visually-formatted plaintext format. ;-) If all code was auto-formatted, you won't have this kind of problem, since the diff utility would compare syntax trees instead of lines, and would show you what *actually* changed syntactically. As opposed to diffs where inserting a new function with a similar body to the following adjacent function causes the diff to be a messy interlacing of lines from both functions, 'cos it's "shorter" than a diff which simply inserts the new function. (Which happens a lot with code that has lots of boilerplate. But boilerplates are another issue. :-)) T -- My program has no bugs! Only unintentional features...
Re: indent style for D
On 30 January 2012 03:27, H. S. Teoh wrote: > On Mon, Jan 30, 2012 at 01:57:43AM +0100, Timon Gehr wrote: >> More practical than requiring all source files to be saved without >> formatting: >> >> - Upon opening a file, the editor looks for a style sheet in the >> same directory. If there is no such style sheet, it automatically >> deduces the style from the code, falling back to the local >> preferences. >> >> - Then it acts as you propose. >> >> - And when saving, it automatically formats the source code in the >> deduced format. > > The problem with autoformatting on save is that it interacts badly with > revision control systems. You could end up with lots of noisy diffs > mostly involving changes in whitespace. By enforcing a fixed formatting, > whether it's everything-on-a-line or delete all unnecessary whitespace > but leave newlines intact, you ensure that diffs generated by the > revision control system will not include whitespace noise. > The flip side is that if you put everything on one line, no one will be able to understand the commits you make. :) -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Re: indent style for D
On Mon, Jan 30, 2012 at 01:57:43AM +0100, Timon Gehr wrote: > More practical than requiring all source files to be saved without > formatting: > > - Upon opening a file, the editor looks for a style sheet in the > same directory. If there is no such style sheet, it automatically > deduces the style from the code, falling back to the local > preferences. > > - Then it acts as you propose. > > - And when saving, it automatically formats the source code in the > deduced format. The problem with autoformatting on save is that it interacts badly with revision control systems. You could end up with lots of noisy diffs mostly involving changes in whitespace. By enforcing a fixed formatting, whether it's everything-on-a-line or delete all unnecessary whitespace but leave newlines intact, you ensure that diffs generated by the revision control system will not include whitespace noise. T -- Debian GNU/Linux: Cray on your desktop.
Re: indent style for D
On Sun, Jan 29, 2012 at 07:13:14PM -0600, Sean Cavanaugh wrote: [...] > There are huge swaths of unused unicode values, including a rather > large chunk reserved for custom user-implementation. > > Clearly we need to redesign the language to use custom symbols that > make sense, instead of the archaic typesetting symbols we use now and > have a unique set of programmer symbols. [...] Why bother with custom symbols? Unicode already gives us entire ranges of mathematical and technical symbols that we could use to our hearts' content. For example, I would love to have new matching pairs of delimiters, such as «» that we could use for, say, template parameters, instead of uglinessess like !. And I'd love to have my integer set class be able to use ∪ and ∩ instead of verbose operations like x.union(y) and x.intersection(y). For that matter, most function names can be reduced to single symbols like ⌹. And we can rename D2 to APL2. ;-) T -- Tell me and I forget. Teach me and I remember. Involve me and I understand. -- Benjamin Franklin
Re: indent style for D
On 1/29/2012 2:44 PM, bearophile wrote: Walter: What? How could the compiler possibly know what font was used in your editor? Sorry Walter, this time I wasn't serious :-) All I can say is, I'm glad. That was a heluva WTF!
Re: indent style for D
On 1/29/2012 2:41 PM, Kagamin wrote: On Sunday, 29 January 2012 at 20:53:51 UTC, Walter Bright wrote: tolf AFAIK, only windows notepad can't handle lf nowadays. That's it? So far, I've seen no issues with standardizing on LF line endings.
Re: indent style for D
On 29/01/2012 19:26, Marco Leise wrote:
Then again "tabs for indentation only" is a simple rule, that would have turned
the tabs
into spaces in this example - if editors supported it.
But when alignment spaces begin at the beginning of the line, or immediately after the
indentation tabs, they can easily be mistaken by editors for indentation and changed to
tabs. It depends on how intelligent the software is.
void qwert(int yuiop, string asdfg, immutable(int)[] hjkl,
Object zxcvb)
Here, the lines of parameters are aligned. However, a naive editor might mistake the
alignment spaces for indentation spaces and turn them into tabs.
void qwert(int yuiop, string asdfg, immutable(int)[] hjkl,
Object zxcvb)
Here, there is a fixed indentation.
But one possibility for editors is to work on the principle that it's an indentation
tab/run of spaces iff the syntactic structure ({}, control statements with a single
statement as body, possibility [] used for array initialisers) dictates that there should
be an indentation tab there. While not perfect, it would still IMO be better than the
current mess many editors are in.
Stewart.
Re: indent style for D
On 30/01/2012 01:13, Sean Cavanaugh wrote: Clearly we need to redesign the language to use custom symbols that make sense, instead of the archaic typesetting symbols we use now and have a unique set of programmer symbols. It's already been tried (APL). OK, so maybe the "that make sense" aspect doesn't apply there. We can even solve the space vs tab problem once and for all, by making a whitespace key and removing the obsolete buttons to make room for all the new ones (which would be tab, spacebar, and enter). Having to switch keyboards might have been another reason people hated APL. Stewart.
Re: indent style for D
On 1/29/2012 5:03 PM, Iain Buclaw wrote: On 29 January 2012 14:17, bearophile wrote: Denis Shelomovskij: Am I mistaken? If no, am I missing some major spaces advantages? If no, lets use tabs. D2 style guide should *require* D2 to be edited using a mono-spaced font, and the D2 front-end should enforce this with a "-ms" compiler switch. Bye, bearophile I think D should go even further than that and drop those horrid curly braces, handling all code blocks by indentation. There are huge swaths of unused unicode values, including a rather large chunk reserved for custom user-implementation. Clearly we need to redesign the language to use custom symbols that make sense, instead of the archaic typesetting symbols we use now and have a unique set of programmer symbols. We can even solve the space vs tab problem once and for all, by making a whitespace key and removing the obsolete buttons to make room for all the new ones (which would be tab, spacebar, and enter).
Re: indent style for D
More practical than requiring all source files to be saved without formatting: - Upon opening a file, the editor looks for a style sheet in the same directory. If there is no such style sheet, it automatically deduces the style from the code, falling back to the local preferences. - Then it acts as you propose. - And when saving, it automatically formats the source code in the deduced format.
Re: indent style for D
On Sunday, January 29, 2012 23:44:25 Iain Buclaw wrote: > On 29 January 2012 23:30, Matej Nanut wrote: > > I like the look of 8-space indents, but I don't see how I could pull > > it off if I use object-oriented features. I use 8-space indents if I > > code C, and it seems to work really well. But when you have a class, > > and then maybe even an inner class, you practically start with 2 > > levels of indentation, and that's where half your "page" (screen) is > > blank space! > > > > What is a solution to this, apart from using 4-space indentation? To > > not indent class declarations is kinda one. > > The answer to that is that if you need more than 3 levels of > indentation, you're screwed anyway, and should fix your program. :o) That doesn't hold for D. There are too many ways to legitimately end up with several levels of indentation. Templates, static ifs, version blocks, struct/class declarations, if/else, while, etc. 3 or 4 levels of indentation is not necessarily uncommon at all. C has so few things that result in new blocks to indent, that the 3 levels of indentation rule has some merit there. But in OO languages (and especially in D with its additional conditional compilation features), that just doesn't fly. - Jonathan M Davis
Re: indent style for D
On 01/30/12 00:03, Iain Buclaw wrote: > On 29 January 2012 14:17, bearophile wrote: >> Denis Shelomovskij: >> >>> Am I mistaken? If no, am I missing some major spaces advantages? If no, >>> lets use tabs. >> >> D2 style guide should *require* D2 to be edited using a mono-spaced font, >> and the D2 front-end should enforce this with a "-ms" compiler switch. >> >> Bye, >> bearophile > > > I think D should go even further than that and drop those horrid curly > braces, handling all code blocks by indentation. http://delight.sourceforge.net/ I was going to suggest making the compiler enforce using black-on-white, instead of white-on-black, for all D soure code, but was afraid somebody would still not get it... :) artur
Re: indent style for D
Le 30/01/2012 00:44, Iain Buclaw a écrit : On 29 January 2012 23:30, Matej Nanut wrote: I like the look of 8-space indents, but I don't see how I could pull it off if I use object-oriented features. I use 8-space indents if I code C, and it seems to work really well. But when you have a class, and then maybe even an inner class, you practically start with 2 levels of indentation, and that's where half your "page" (screen) is blank space! What is a solution to this, apart from using 4-space indentation? To not indent class declarations is kinda one. The answer to that is that if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program. :o) Well, not to mention that this sentence first apply to C. Because if you apply that in some programming languages, you'll be screwed up pretty quickly (even in D even if it isn't the worse at this game).
Re: indent style for D
On 29 January 2012 23:30, Matej Nanut wrote: > I like the look of 8-space indents, but I don't see how I could pull > it off if I use object-oriented features. I use 8-space indents if I > code C, and it seems to work really well. But when you have a class, > and then maybe even an inner class, you practically start with 2 > levels of indentation, and that's where half your "page" (screen) is > blank space! > > What is a solution to this, apart from using 4-space indentation? To > not indent class declarations is kinda one. The answer to that is that if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program. :o) -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Re: indent style for D
I like the look of 8-space indents, but I don't see how I could pull it off if I use object-oriented features. I use 8-space indents if I code C, and it seems to work really well. But when you have a class, and then maybe even an inner class, you practically start with 2 levels of indentation, and that's where half your "page" (screen) is blank space! What is a solution to this, apart from using 4-space indentation? To not indent class declarations is kinda one.
Re: indent style for D
H. S. Teoh: > You know, I'm starting to take seriously bearophile's (I think it was > him?) half-joking proposal that all code must be written on a single > line, It wasn't me. Bye, bearophile
Re: indent style for D
On Sun, Jan 29, 2012 at 11:03:54PM +, Iain Buclaw wrote: [...] > I think D should go even further than that and drop those horrid curly > braces, handling all code blocks by indentation. [...] Yeah, that way D will have much less competition to succeed (only have to beat Python instead of out-competing thousands of other languages). ;-) T -- One reason that few people are aware there are programs running the internet is that they never crash in any significant way: the free software underlying the internet is reliable to the point of invisibility. -- Glyn Moody, from the article "Giving it all away"
Re: indent style for D
On Sun, Jan 29, 2012 at 02:32:48PM -0800, Jonathan M Davis wrote:
> On Sunday, January 29, 2012 14:27:29 H. S. Teoh wrote:
[...]
> > I always code with tab stops set to 8 and line wrapping set to 80
> > columns.
>
> That's not going to work very well with D. You tend to get far too
> many levels of indentation for that to fly. With static if (and
> potentiall multiple layers of static if), classes, templates, etc. all
> on top of the normal if statements and while loops and the like, and
> it can very quickly reach 3 - 4 indentation levels on simple code, let
> alone what more complex code has. It's that much worse when you use
> much in the way of functional-style programming and chain function
> calls, since then not are the lines indented a fair ways, but they
> tend to get long. I suspect that you'll find 8 character tabs and 80
> character columns to be a frustrating combination, but you can do
> whatever you want.
I used to use 2-space indentation for this very reason. I've written
Perl code with 16 levels of nesting complete with chained maps{} and
other such fun stuff.
But I've since changed my mind, and have come to believe that if a
function requires more than 3-4 levels of nesting, there is a
fundamental design problem with it, and it should be split into smaller
functions. This also helps you refactor code more easily as well as give
you a reason to think about how to better express what you're trying to
do, instead of just going on auto-pilot and using 8 levels of nesting
just because.
Optimizing compilers like gdc will auto-inline single-use functions
anyway, so this shouldn't be a problem even on the premature
optimization side. ;-)
Besides, one of the things I really love about D is closures... with
careful use of closures, almost any code can be reduced to 3-4 indents
at the most, usually only 2-3.
> Phobos uses 4 character tabs with a soft limit of 80 characters (on
> average, a line should fit within 80 characters, but it doesn't have
> to) and a hard limit of 120 characters (a line should _never_ exceed
> 120 characters). And that seems to be working fairly well for us.
[...]
Well, having worked in many different projects under different managers
with different coding styles at my full-time jobs, I've come to accept
that when writing code for a particular project, one should simply
follow whatever conventions existing code in that project uses, however
ugly it may seem. For my own projects, though, I use 8-space tabs and
80-column wrapping.
T
--
2+2=4. 2*2=4. 2^2=4. Therefore, +, *, and ^ are the same operation.
Re: indent style for D
On 29 January 2012 14:17, bearophile wrote: > Denis Shelomovskij: > >> Am I mistaken? If no, am I missing some major spaces advantages? If no, >> lets use tabs. > > D2 style guide should *require* D2 to be edited using a mono-spaced font, and > the D2 front-end should enforce this with a "-ms" compiler switch. > > Bye, > bearophile I think D should go even further than that and drop those horrid curly braces, handling all code blocks by indentation. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Re: indent style for D
On Sun, Jan 29, 2012 at 12:36:18PM +0100, Trass3r wrote:
> >http://www.d-programming-language.org/dstyle.html in regard to
> >indent-style, can someone shed some light what is recommended
> >practice for it within D community?
>
> Everyone thinks his way is the best.
You know, I'm starting to take seriously bearophile's (I think it was
him?) half-joking proposal that all code must be written on a single
line, and whatever editor/IDE/what-have-you that you use to code will
pretty-print everything for you. That way, everyone will see the code in
their own favorite style, and nobody will have pointless flamewars over
this subject ever again (thereby giving more time for more important
things, such as vim vs. emacs flamewars :P).
I mean, if you think about it, at the most fundamental level, whether
you use spaces or tabs or what-not, it's all *visual formatting* done in
a format that's essentially conveying *semantic information* to the
compiler. It's just like the tag in HTML (that we finally got rid
of after years of pain).
And let's face it. A space character is intended to represent an
inter-word space. It's not supposed to represent *indentation*. That
privilege is reserved for the tab character. But unfortunately there is
no consensus on how wide a tab is supposed to be.
But all of this is missing the point. Code is essentially a
tree-structured thing, consisting of nested blocks. Why should we use
ill-suited representations as tabs and spaces for nesting blocks? There
should be a dedicated code-editor (or vim/emacs mode, or IDE
configuration, or whatever), that parses the damn code and displays the
nesting structure in whatever way the user wants to see it. Whether you
want to see your blocks like this:
if (a < b) {
a = b;
} else {
b = a;
}
or
if (a < b)
{
a = b;
}
else
{
b = a;
}
or even
if (a < b) { a = b; } else { b = a }
or worse:
if (a < b) {
a = b;
}
else {
b = a;
}
(I kid you not, I know at least one person who actually writes code like
that) ... really shouldn't require painful reformatting of the entire
source code. You should be able to load a "style sheet" into your
editor that automatically parses the code and pretty-prints (or
ugly-prints) it in your favorite style.
And not only so, when you type, it automatically formats blocks for you
with no further effort. You type "if(a
Re: indent style for D
On Sunday, 29 January 2012 at 22:25:57 UTC, H. S. Teoh wrote: *Text* is easier to read with proportional fonts. Code is not the same as text. Tried many monospaced fonts, none is more readable than verdana.
Re: indent style for D
Walter: > What? How could the compiler possibly know what font was used in your editor? Sorry Walter, this time I wasn't serious :-) Bye, bearophile
Re: indent style for D
On Sunday, 29 January 2012 at 20:53:51 UTC, Walter Bright wrote: tolf AFAIK, only windows notepad can't handle lf nowadays. That's it?
Re: indent style for D
On Sunday, January 29, 2012 14:27:29 H. S. Teoh wrote: > On Sun, Jan 29, 2012 at 05:33:39PM +, Russel Winder wrote: > > On Sun, 2012-01-29 at 09:17 -0500, bearophile wrote: > [...] > > > > D2 style guide should *require* D2 to be edited using a mono-spaced > > > font, and the D2 front-end should enforce this with a "-ms" compiler > > > switch. > > > > Surely this is a level of fascism too far (*). Using monospace fonts is > > just so 1960s, the era of typewriters and 80x25 terminals. > > I always code with tab stops set to 8 and line wrapping set to 80 > columns. That's not going to work very well with D. You tend to get far too many levels of indentation for that to fly. With static if (and potentiall multiple layers of static if), classes, templates, etc. all on top of the normal if statements and while loops and the like, and it can very quickly reach 3 - 4 indentation levels on simple code, let alone what more complex code has. It's that much worse when you use much in the way of functional-style programming and chain function calls, since then not are the lines indented a fair ways, but they tend to get long. I suspect that you'll find 8 character tabs and 80 character columns to be a frustrating combination, but you can do whatever you want. Phobos uses 4 character tabs with a soft limit of 80 characters (on average, a line should fit within 80 characters, but it doesn't have to) and a hard limit of 120 characters (a line should _never_ exceed 120 characters). And that seems to be working fairly well for us. - Jonathan M Davis
Re: indent style for D
On Sun, Jan 29, 2012 at 05:33:39PM +, Russel Winder wrote: > On Sun, 2012-01-29 at 09:17 -0500, bearophile wrote: [...] > > D2 style guide should *require* D2 to be edited using a mono-spaced > > font, and the D2 front-end should enforce this with a "-ms" compiler > > switch. > > Surely this is a level of fascism too far (*). Using monospace fonts is > just so 1960s, the era of typewriters and 80x25 terminals. I always code with tab stops set to 8 and line wrapping set to 80 columns. > Personally I am living in an era where monitors deal with proportional > fonts which every experiment done shows are easier to read. *Text* is easier to read with proportional fonts. Code is not the same as text. > Why do so many programmers hanker for the 1960s and the necessity of > monospace fonts, it seems irrational. I am irrational. ;-) T -- I am a consultant. My job is to make your job redundant. -- Mr Tom
Re: indent style for D
On Sun, Jan 29, 2012 at 10:47:55PM +0400, Denis Shelomovskij wrote: > 29.01.2012 22:07, Stewart Gordon пишет: > >It is. But mishmashing tab and space indentation causes far worse > >conflict. > > > >Iain - I take it you meant that mishmashing, combined with users > >having different tab size settings, causes a problem. Correct? > > > >Stewart. > > Looks the reason against tabs is: mixed tabs and spaces is bad. So we > should use spaces. [...] My opinion is that there is no problem if you indent with tabs, with spaces only added to the end of the run of tabs if necessary. Comments and code never mix on the same line. This way, no matter what how wide you set your tab stops to, things will always line up correctly. (Sadly I don't follow this rule 100% of the time...) T -- Без труда не выловишь и рыбку из пруда.
Re: indent style for D
Am 29.01.2012, 20:32 Uhr, schrieb Derek :
On Mon, 30 Jan 2012 01:04:43 +1100, Denis Shelomovskij
wrote:
* Such tab using shows respect to a programmer allowing him to
configure tab size as he prefer.
This works ok for editors, but I can't work out how to configure my
browser's tab-stops or the console's or printer's either for that
matter. The issue is how to /display/ code in a reader-friendly manner.
If you are the web-master, you use the corresponding CSS3 attribute
http://www.w3.org/TR/css3-text/#tab-size and make it configurable.
If you are the user, create a .css file with the following line, replacing
99 with the width in spaces you prefer:
* { -moz-tab-size: 99; -o-tab-size: 99; tab-size: 99; }
In Opera:
- Press Ctrl+F12 to open the settings dialog
- Select the 'Advanced' tab
- Click on 'Content' in the list to the left
- Click on the 'Style Options...' button
- Under 'My style sheet' browse to and select your .css file
FireFox:
http://www.tweakguides.com/Firefox_12.html
Chrome:
http://darcyclarke.me/design/skin-your-chrome-inspector/
Use some website like this one as a test:
http://www.didihome.de/html/txt-tab.htm
Re: indent style for D
Am 29.01.2012, 21:20 Uhr, schrieb Timon Gehr : On 01/29/2012 08:26 PM, Marco Leise wrote: Am 29.01.2012, 16:23 Uhr, schrieb Trass3r : Am I mistaken? If no, am I missing some major spaces advantages? If no, lets use tabs. Perhaps, there is no tool that will convert (convert right, not somehow, see article) tabs<->spaces in D code. There wouldn't be any problem if people were able to use tabs for indentation and spaces for alignment, i.e. in cases like if (cond1 && cond2) But people are dumb and many project leaders "take no risks" and require spaces everywhere instead of doing it properly. If it cheers you up, I use that style. Once you get used to 'smart tabs' it is like using spaces. Just now and then I catch myself using tabs on the alignment for local variable comments: int foo; // does something (tabs) int bar; // something else (spaces) Then again "tabs for indentation only" is a simple rule, that would have turned the tabs into spaces in this example - if editors supported it. *Real* editors can be configured to support smart tabs. I sense a hint to some obscure Unix tool like vim or emacs.
Re: indent style for D
30.01.2012 0:53, Walter Bright пишет: On 1/29/2012 10:53 AM, Denis Shelomovskij wrote: No, it isn't. Spaces aren't comfortable to use in existed editors. Right, and I use tabs in my editor. I also run all files through the tools: detab to convert my tabs to spaces ... Works like a champ. I will be happy once I will find a working tool for reverse operation. But yes, partially working one is enough for manual editing in the case everything will be converted to spaces at commit. Thanks, an easy partial solution sometimes isn't obvious.
Re: indent style for D
29.01.2012 22:42, Walter Bright пишет: On 1/29/2012 6:17 AM, bearophile wrote: D2 style guide should *require* D2 to be edited using a mono-spaced font, and the D2 front-end should enforce this with a "-ms" compiler switch. What? How could the compiler possibly know what font was used in your editor? This can be passed by user as a compiler switch, something like: dmd -ms -font=Courier-i-swear srcfile.d
Re: indent style for D
30.01.2012 0:42, Walter Bright пишет: On 1/29/2012 6:17 AM, bearophile wrote: D2 style guide should *require* D2 to be edited using a mono-spaced font, and the D2 front-end should enforce this with a "-ms" compiler switch. What? How could the compiler possibly know what font was used in your editor? It's your compiler, Walter! You should be more sensible and keep silence while people praise you instead of acknowledging your own feebleness. More than that, people can use some piratical or even terrorist font to program in D and in our bright future you will answer in law (some modified SOPA, "Genuine Patriot Act" or smth. another).
Re: indent style for D
On 01/29/2012 06:52 PM, Sean Cavanaugh wrote:
On 1/29/2012 5:36 AM, Trass3r wrote:
http://www.d-programming-language.org/dstyle.html in regard to
indent-style, can someone shed some light what is recommended practice
for it within D community?
Everyone thinks his way is the best.
Thats because it is :)
curley braces on the same line as conditionals is a refactoring landmine
IMO
I've never seen an editor that would enforce only leading characters on
a line as tabs,
makefile-mode in GNU emacs highlights leading spaces and points out
their existence on saving. But that is not the right behavior for all
languages:
void main(){
\t auto x = ["abcd",
\t .."defg",
\t .. ...
\t .];
}
and until all of them do it, spaces is the only thing
that makes sense to me, since they are never 'wrong'.
You mean invisibly wrong for some tab-settings.
void main(){
.int i;
..int j = 2;
...for(;i
The codebase I use at work is full of tabs and I can tolerate them, but
not knowing how many times to hit backspace on some chunk of code
containing whitespace in the middle of it is really annoying. Yes there
is undo but it starts infringing on my flow (replacing zen with anger,
the emperor would be pleased . . .)
That is an editor-specific problem. In my editor, hitting backspace
always deletes one character (and converts the remaining portion of a
tab to spaces).
Re: indent style for D
29.01.2012 23:02, Iain Buclaw пишет:
On 29 January 2012 18:11, Denis Shelomovskij
wrote:
29.01.2012 18:09, Iain Buclaw пишет:
On 29 January 2012 14:04, Denis Shelomovskij
wrote:
29.01.2012 15:21, Alex Rønne Petersen пишет:
On 29-01-2012 10:15, Gour wrote:
Hello!
It was mentioned in #D that gdc will probably adapt its code to GNU
code
style and I wonder, seeing no recemmendation in
http://www.d-programming-language.org/dstyle.html in regard to
indent-style, can someone shed some light what is recommended practice
for it within D community?
Sincerely,
Gour
Phobos generally uses 4-space indentation.
I don't think there is the best coding style (personally I like both K&R
and
Allman styles). IMHO things are different with indention. Why does Phobos
use 4-space indentation?
The following article (IMHO) completely covers tabs vs spaces problem:
http://www.emacswiki.org/cgi-bin/wiki/TabsAreEvil
It shows that tabs (in spite of the article title) are really good and
should be used always (and only) for indention. Looks like Allman style
doesn't prevent this (if it does, what is the reason?). So:
* Such tab using shows respect to a programmer allowing him to configure
tab
size as he prefer.
* Sometimes indention should be changed for a particular using.
* Worst of all, sometimes same code is used in different places where
different indention levels are expected.
* Using spaces guarantee that code will look same in every editor but it
is
the simplest and not the most convenient way, the code should look _good
for
every editor user_, not _same_, so it tears down our community.
* It's less comfortable to use spaces for indention in every editor I use
(at least because spaces allows caret position in the middle of indention
and pressingdeletes one space instead of
the
indention level, so it's easy to accidentally broke indention and use,
e.g.
7 instead of 8 spaces).
And this isn't only a theory. In practice:
* I've never liked 8-chars indention, so I feels myself bad in d-p-l.org
sources. Probably I'm not the only one.
* I accidentally brake spaces indention sometimes. Probably I'm not the
less-trained-in-printing one.
* Some time ago a ebook version of d-p-l.org has been created. Walter had
to
change every 4-spaces indention in examples to 2-spaces indention for
convenience reading on small PPC screen.
* Now everyone see 2-spaces indented examples in d-p-l.org instead of
his,
probably, preferred 4-spaces indented.
Am I mistaken? If no, am I missing some major spaces advantages? If no,
lets
use tabs. Perhaps, there is no tool that will convert (convert right, not
somehow, see article) tabs<->spaces in D code.
The problem is lines with mixed tabs and spaces, and different users
set their text editors see tabs differently. ie: is your tab-width set
to 2, 3, 4, or 8?
Example, please.
P.S.
Have you read the article? (I'm asking that just because I can't imagine an
example or I don't clearly understand what do you mean)
eg:
{
...->test1();
->test2();
..->test3();
}
If someone has their tabs aligned to 4 characters or higher, they will
see the above as if they are indented to the same offset, any less,
and things get interesting:
tabstop=4;'
{
test();
test2();
test3();
}
tabstop=3;
{
test1();
test2();
test3();
}
tabstop=2;
{
test1();
test2();
test3();
}
tabstop=1;
{
test1();
test2();
test3();
}
Even worse, it still depends on editor - it can just add N to current
position instead of moving to the next tab stop.
But in spite of everything I will quote my post:
>Looks the reason against tabs is: mixed tabs and spaces is bad. So we
>should use spaces.
>Khm... Will it be in tab's favour if I rewrite the reason as "mixed
>spaces and tabs is bad"?
Re: indent style for D
On 1/29/2012 10:53 AM, Denis Shelomovskij wrote: No, it isn't. Spaces aren't comfortable to use in existed editors. Right, and I use tabs in my editor. I also run all files through the tools: detab to convert my tabs to spaces and: tolf to convert to LF line endings before checkin. Works like a champ.
Re: indent style for D
On 1/29/2012 6:04 AM, Denis Shelomovskij wrote: Why does Phobos use 4-space indentation? Because it works, changing it would be a vast waste of time for a non-existent benefit, and it would become a nuisance to do diffs of source code that cross the re-whitespace boundary. The style for Phobos is 4 space indentation, no tab characters anywhere, and LF line endings (to make github happy).
Re: indent style for D
On 1/29/2012 6:17 AM, bearophile wrote: D2 style guide should *require* D2 to be edited using a mono-spaced font, and the D2 front-end should enforce this with a "-ms" compiler switch. What? How could the compiler possibly know what font was used in your editor?
Re: indent style for D
On 01/29/2012 08:26 PM, Marco Leise wrote: Am 29.01.2012, 16:23 Uhr, schrieb Trass3r : Am I mistaken? If no, am I missing some major spaces advantages? If no, lets use tabs. Perhaps, there is no tool that will convert (convert right, not somehow, see article) tabs<->spaces in D code. There wouldn't be any problem if people were able to use tabs for indentation and spaces for alignment, i.e. in cases like if (cond1 && cond2) But people are dumb and many project leaders "take no risks" and require spaces everywhere instead of doing it properly. If it cheers you up, I use that style. Once you get used to 'smart tabs' it is like using spaces. Just now and then I catch myself using tabs on the alignment for local variable comments: int foo; // does something (tabs) int bar; // something else (spaces) Then again "tabs for indentation only" is a simple rule, that would have turned the tabs into spaces in this example - if editors supported it. *Real* editors can be configured to support smart tabs.
Re: indent style for D
On Mon, 30 Jan 2012 01:04:43 +1100, Denis Shelomovskij wrote: * Such tab using shows respect to a programmer allowing him to configure tab size as he prefer. This works ok for editors, but I can't work out how to configure my browser's tab-stops or the console's or printer's either for that matter. The issue is how to /display/ code in a reader-friendly manner. -- Derek Parnell Melbourne, Australia
Re: indent style for D
Am 29.01.2012, 16:23 Uhr, schrieb Trass3r : Am I mistaken? If no, am I missing some major spaces advantages? If no, lets use tabs. Perhaps, there is no tool that will convert (convert right, not somehow, see article) tabs<->spaces in D code. There wouldn't be any problem if people were able to use tabs for indentation and spaces for alignment, i.e. in cases like if (cond1 && cond2) But people are dumb and many project leaders "take no risks" and require spaces everywhere instead of doing it properly. If it cheers you up, I use that style. Once you get used to 'smart tabs' it is like using spaces. Just now and then I catch myself using tabs on the alignment for local variable comments: int foo;// does something (tabs) int bar;// something else (spaces) Then again "tabs for indentation only" is a simple rule, that would have turned the tabs into spaces in this example - if editors supported it.
Re: indent style for D
Manfred Nowak wrote: > deadalnix wrote: > >> I would say that the most important is to be consistent accros a >> project > > If it is indead important, then the project shoud have a tool that can > enforce that style. And every coder should have a tool that enforces > her/his indiviuell style, if she/he cannot cope with that style. > > Ever heard of any one having such a tool? > > -manfred http://uncrustify.sourceforge.net/ It even supports D... Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: indent style for D
Am 29.01.2012, 12:43 Uhr, schrieb Jonathan M Davis : On Sunday, January 29, 2012 12:34:22 Gour wrote: On Sun, 29 Jan 2012 12:21:35 +0100 Alex Rønne Petersen wrote: > Phobos generally uses 4-space indentation. That is mentioned in the style-guide, but I'm curious about bracing, iow, GNUstyle, K&R, ANSI...? Phobos uses Allman: http://en.wikipedia.org/wiki/Indent_style#Allman_style But everyone is free to format their code how they like. Personally, I've never understood how anyone can stand anything other than Allman, but to each their own, I suppose. - Jonathan M Davis I have 31 visible lines of code in Eclipse, I need to conserve some space. Otherwise I like that style and use it for top-level struct/class declarations.
Re: indent style for D
On 29 January 2012 18:11, Denis Shelomovskij
wrote:
> 29.01.2012 18:09, Iain Buclaw пишет:
>>
>> On 29 January 2012 14:04, Denis Shelomovskij
>> wrote:
>>>
>>> 29.01.2012 15:21, Alex Rønne Petersen пишет:
>>>
>>>
On 29-01-2012 10:15, Gour wrote:
>
>
> Hello!
>
> It was mentioned in #D that gdc will probably adapt its code to GNU
> code
> style and I wonder, seeing no recemmendation in
> http://www.d-programming-language.org/dstyle.html in regard to
> indent-style, can someone shed some light what is recommended practice
> for it within D community?
>
>
> Sincerely,
> Gour
>
Phobos generally uses 4-space indentation.
>>>
>>> I don't think there is the best coding style (personally I like both K&R
>>> and
>>> Allman styles). IMHO things are different with indention. Why does Phobos
>>> use 4-space indentation?
>>>
>>> The following article (IMHO) completely covers tabs vs spaces problem:
>>> http://www.emacswiki.org/cgi-bin/wiki/TabsAreEvil
>>>
>>> It shows that tabs (in spite of the article title) are really good and
>>> should be used always (and only) for indention. Looks like Allman style
>>> doesn't prevent this (if it does, what is the reason?). So:
>>> * Such tab using shows respect to a programmer allowing him to configure
>>> tab
>>> size as he prefer.
>>> * Sometimes indention should be changed for a particular using.
>>> * Worst of all, sometimes same code is used in different places where
>>> different indention levels are expected.
>>> * Using spaces guarantee that code will look same in every editor but it
>>> is
>>> the simplest and not the most convenient way, the code should look _good
>>> for
>>> every editor user_, not _same_, so it tears down our community.
>>> * It's less comfortable to use spaces for indention in every editor I use
>>> (at least because spaces allows caret position in the middle of indention
>>> and pressing deletes one space instead of
>>> the
>>> indention level, so it's easy to accidentally broke indention and use,
>>> e.g.
>>> 7 instead of 8 spaces).
>>>
>>> And this isn't only a theory. In practice:
>>> * I've never liked 8-chars indention, so I feels myself bad in d-p-l.org
>>> sources. Probably I'm not the only one.
>>> * I accidentally brake spaces indention sometimes. Probably I'm not the
>>> less-trained-in-printing one.
>>> * Some time ago a ebook version of d-p-l.org has been created. Walter had
>>> to
>>> change every 4-spaces indention in examples to 2-spaces indention for
>>> convenience reading on small PPC screen.
>>> * Now everyone see 2-spaces indented examples in d-p-l.org instead of
>>> his,
>>> probably, preferred 4-spaces indented.
>>>
>>> Am I mistaken? If no, am I missing some major spaces advantages? If no,
>>> lets
>>> use tabs. Perhaps, there is no tool that will convert (convert right, not
>>> somehow, see article) tabs<->spaces in D code.
>>
>>
>> The problem is lines with mixed tabs and spaces, and different users
>> set their text editors see tabs differently. ie: is your tab-width set
>> to 2, 3, 4, or 8?
>>
>
> Example, please.
>
> P.S.
> Have you read the article? (I'm asking that just because I can't imagine an
> example or I don't clearly understand what do you mean)
eg:
{
...->test1();
->test2();
..->test3();
}
If someone has their tabs aligned to 4 characters or higher, they will
see the above as if they are indented to the same offset, any less,
and things get interesting:
tabstop=4;'
{
test();
test2();
test3();
}
tabstop=3;
{
test1();
test2();
test3();
}
tabstop=2;
{
test1();
test2();
test3();
}
tabstop=1;
{
test1();
test2();
test3();
}
--
Iain Buclaw
*(p < e ? p++ : p) = (c & 0x0f) + '0';
Re: indent style for D
29.01.2012 21:29, Russel Winder пишет: On Sun, 2012-01-29 at 14:09 +, Iain Buclaw wrote: [...] The problem is lines with mixed tabs and spaces, and different users set their text editors see tabs differently. ie: is your tab-width set to 2, 3, 4, or 8? Isn't that the whole point: using spaces causes conflict over indentation, using tabs, 1 per indent level, allows individuals to choose their indent level. No, it isn't. Spaces aren't comfortable to use in existed editors. In spite of the fact that they provide a lot of support for N spaces to behave like a tab. And it unnecessary complicates editors (they can implement something more useful instead, like elastic tabstops from Trass3r's post).
Re: indent style for D
29.01.2012 22:07, Stewart Gordon пишет: It is. But mishmashing tab and space indentation causes far worse conflict. Iain - I take it you meant that mishmashing, combined with users having different tab size settings, causes a problem. Correct? Stewart. Looks the reason against tabs is: mixed tabs and spaces is bad. So we should use spaces. Khm... Will it be in tab's favour if I rewrite the reason as "mixed spaces and tabs is bad"?
Re: indent style for D
On Sunday, 29 January 2012 at 16:48:18 UTC, bearophile wrote: Stewart Gordon: What do you mean by the "D2 front-end"? It was one of my first attempts at humor :-) Bye and sorry, bearophile Don't worry I had a good laugh.
Re: indent style for D
On Sun, 2012-01-29 at 18:07 +, Stewart Gordon wrote: [...] > It is. But mishmashing tab and space indentation causes far worse conflict. Agreed -- homogeneity of the character used for spacing, especially indentation, is critical . I think this is why Emacs (*) has a way of converting all leading whitespace to either tabs or spaces. (*) The only one true editor (and kitchen sink). -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: indent style for D
29.01.2012 18:09, Iain Buclaw пишет: On 29 January 2012 14:04, Denis Shelomovskij wrote: 29.01.2012 15:21, Alex Rønne Petersen пишет: On 29-01-2012 10:15, Gour wrote: Hello! It was mentioned in #D that gdc will probably adapt its code to GNU code style and I wonder, seeing no recemmendation in http://www.d-programming-language.org/dstyle.html in regard to indent-style, can someone shed some light what is recommended practice for it within D community? Sincerely, Gour Phobos generally uses 4-space indentation. I don't think there is the best coding style (personally I like both K&R and Allman styles). IMHO things are different with indention. Why does Phobos use 4-space indentation? The following article (IMHO) completely covers tabs vs spaces problem: http://www.emacswiki.org/cgi-bin/wiki/TabsAreEvil It shows that tabs (in spite of the article title) are really good and should be used always (and only) for indention. Looks like Allman style doesn't prevent this (if it does, what is the reason?). So: * Such tab using shows respect to a programmer allowing him to configure tab size as he prefer. * Sometimes indention should be changed for a particular using. * Worst of all, sometimes same code is used in different places where different indention levels are expected. * Using spaces guarantee that code will look same in every editor but it is the simplest and not the most convenient way, the code should look _good for every editor user_, not _same_, so it tears down our community. * It's less comfortable to use spaces for indention in every editor I use (at least because spaces allows caret position in the middle of indention and pressing deletes one space instead of the indention level, so it's easy to accidentally broke indention and use, e.g. 7 instead of 8 spaces). And this isn't only a theory. In practice: * I've never liked 8-chars indention, so I feels myself bad in d-p-l.org sources. Probably I'm not the only one. * I accidentally brake spaces indention sometimes. Probably I'm not the less-trained-in-printing one. * Some time ago a ebook version of d-p-l.org has been created. Walter had to change every 4-spaces indention in examples to 2-spaces indention for convenience reading on small PPC screen. * Now everyone see 2-spaces indented examples in d-p-l.org instead of his, probably, preferred 4-spaces indented. Am I mistaken? If no, am I missing some major spaces advantages? If no, lets use tabs. Perhaps, there is no tool that will convert (convert right, not somehow, see article) tabs<->spaces in D code. The problem is lines with mixed tabs and spaces, and different users set their text editors see tabs differently. ie: is your tab-width set to 2, 3, 4, or 8? Example, please. P.S. Have you read the article? (I'm asking that just because I can't imagine an example or I don't clearly understand what do you mean)
Re: indent style for D
On 29/01/2012 17:29, Russel Winder wrote: On Sun, 2012-01-29 at 14:09 +, Iain Buclaw wrote: [...] The problem is lines with mixed tabs and spaces, and different users set their text editors see tabs differently. ie: is your tab-width set to 2, 3, 4, or 8? Isn't that the whole point: using spaces causes conflict over indentation, using tabs, 1 per indent level, allows individuals to choose their indent level. It is. But mishmashing tab and space indentation causes far worse conflict. Iain - I take it you meant that mishmashing, combined with users having different tab size settings, causes a problem. Correct? Stewart.
Re: indent style for D
29.01.2012 20:48, bearophile пишет: Stewart Gordon: What do you mean by the "D2 front-end"? It was one of my first attempts at humor :-) Bye and sorry, bearophile Thanks for explicitly defining that! You just saved a lot of my time. )
Re: indent style for D
On 1/29/2012 5:36 AM, Trass3r wrote: http://www.d-programming-language.org/dstyle.html in regard to indent-style, can someone shed some light what is recommended practice for it within D community? Everyone thinks his way is the best. Thats because it is :) curley braces on the same line as conditionals is a refactoring landmine IMO I've never seen an editor that would enforce only leading characters on a line as tabs, and until all of them do it, spaces is the only thing that makes sense to me, since they are never 'wrong'. The codebase I use at work is full of tabs and I can tolerate them, but not knowing how many times to hit backspace on some chunk of code containing whitespace in the middle of it is really annoying. Yes there is undo but it starts infringing on my flow (replacing zen with anger, the emperor would be pleased . . .)
Re: indent style for D
Ever heard of any one having such a tool? http://golang.org/cmd/gofmt/
Re: indent style for D
On Sun, 2012-01-29 at 09:17 -0500, bearophile wrote: > Denis Shelomovskij: > > > Am I mistaken? If no, am I missing some major spaces advantages? If no, > > lets use tabs. > > D2 style guide should *require* D2 to be edited using a mono-spaced font, and > the D2 front-end should enforce this with a "-ms" compiler switch. Surely this is a level of fascism too far (*). Using monospace fonts is just so 1960s, the era of typewriters and 80x25 terminals. Personally I am living in an era where monitors deal with proportional fonts which every experiment done shows are easier to read. Why do so many programmers hanker for the 1960s and the necessity of monospace fonts, it seems irrational. (*) Go imposes these sorts of rules, well at least brace placement and indentation levels, and it really irritates. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: indent style for D
On Sun, 2012-01-29 at 14:09 +, Iain Buclaw wrote: [...] > The problem is lines with mixed tabs and spaces, and different users > set their text editors see tabs differently. ie: is your tab-width set > to 2, 3, 4, or 8? Isn't that the whole point: using spaces causes conflict over indentation, using tabs, 1 per indent level, allows individuals to choose their indent level. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: indent style for D
On 29/01/2012 15:39, David wrote: Am 29.01.2012 16:23, schrieb Trass3r: But people are dumb and many project leaders "take no risks" and require spaces everywhere instead of doing it properly. An ever better solution is elastic tabstops, but unfortunately no major editor supports that. Where's the problem, you can configure most editors to insert N-spaces when pressing the tab-key. Some editors are so smart enough to handle the N-spaces still as tabs but save them as spaces. Some editors (Notepad++ included), when configured to do tabs as spaces, only insert _new_ tabs as spaces and leave existing tabs as they are. And when configured do to tabs as tabs, leave existing space indentation alone. And sometimes even more annoyingly, convert spaces to tabs when you block indent/outdent or start a new line. This leads to files that multiple people have worked on being indented with a mishmash of tabs and spaces. Much better would be to: - Preserve the sequence of spaces and tabs when you block indent/outdent - When you insert a line break, copy the sequence of spaces and tabs onto the new line - When you type a tab preceded by only tabs, insert a tab - When you type a tab preceded by characters other than tabs, insert spaces - Attempt to detect the indentation style when opening a file and then follow it - Provide commands to convert tabs to/from spaces separately from block indent/outdent Stewart.
Re: indent style for D
On 01/29/2012 06:54 AM, Trass3r wrote:
Personally, I've never understood how anyone can stand anything other
than Allman.
Totally agree.
Well, people adapt and values change. :)
I've always used Allman style (although learning its name just now),
until I started to work at my current job more than 4 years ago. We use
a modified 1TBS by adding an extra empty line before the else:
if (x < 0) {
puts("Negative");
negative(x);
// <-- added
} else {
puts("Non-negative");
nonnegative(x);
}
I know there isn't one perfect style, but to me, that's the most
recognizable one. Of course I can rationalize it too. :)
Ali
Re: indent style for D
deadalnix wrote: > I would say that the most important is to be consistent accros a > project If it is indead important, then the project shoud have a tool that can enforce that style. And every coder should have a tool that enforces her/his indiviuell style, if she/he cannot cope with that style. Ever heard of any one having such a tool? -manfred
Re: indent style for D
On 29/01/2012 14:17, bearophile wrote: Denis Shelomovskij: Am I mistaken? If no, am I missing some major spaces advantages? If no, lets use tabs. D2 style guide should *require* D2 to be edited using a mono-spaced font, and the D2 front-end should enforce this with a "-ms" compiler switch. What do you mean by the "D2 front-end"? The compiler front-end, or some IDE? If you're talking about the compiler, how will it determine what font was set in the program used to edit the file? Are you planning to make this work even if the file has been edited in more than one editor and/or font over the course of time? If you mean an IDE, what use would a compiler switch be? Just set up the font selection UI to allow only monospaced fonts to be selected. In Windows at least, the font common dialog has a flag to do this. Stewart.
Re: indent style for D
Stewart Gordon: > What do you mean by the "D2 front-end"? It was one of my first attempts at humor :-) Bye and sorry, bearophile
Re: indent style for D
On 29/01/2012 14:17, bearophile wrote: Denis Shelomovskij: Am I mistaken? If no, am I missing some major spaces advantages? If no, lets use tabs. D2 style guide should *require* D2 to be edited using a mono-spaced font, and the D2 front-end should enforce this with a "-ms" compiler switch. What do you mean by the "D2 front-end"? The compiler front-end, or some IDE? If you're talking about the compiler, how will it determine what font was set in the program used to edit the file? Are you planning to make this work even if the file has been edited in more than one editor and/or font over the course of time? If you mean an IDE, what use would a compiler switch be? Just set up the font selection UI to allow only monospaced fonts to be selected. In Windows at least, the font common dialog has a flag to do this. Stewart.
Re: indent style for D
Le 29/01/2012 16:39, David a écrit : Am 29.01.2012 16:23, schrieb Trass3r: But people are dumb and many project leaders "take no risks" and require spaces everywhere instead of doing it properly. An ever better solution is elastic tabstops, but unfortunately no major editor supports that. Where's the problem, you can configure most editors to insert N-spaces when pressing the tab-key. Some editors are so smart enough to handle the N-spaces still as tabs but save them as spaces. So, the point is saving spaces and programing many many tricks in the editor to make spaces behave like tabs. I don't see the point of it. It is just like you were asking for a 4 wheeled motobike with a roof and 5 sits because you don't want a car.
Re: indent style for D
Am 29.01.2012 16:23, schrieb Trass3r: But people are dumb and many project leaders "take no risks" and require spaces everywhere instead of doing it properly. An ever better solution is elastic tabstops, but unfortunately no major editor supports that. Where's the problem, you can configure most editors to insert N-spaces when pressing the tab-key. Some editors are so smart enough to handle the N-spaces still as tabs but save them as spaces.
Re: indent style for D
Am I mistaken? If no, am I missing some major spaces advantages? If no, lets use tabs. Perhaps, there is no tool that will convert (convert right, not somehow, see article) tabs<->spaces in D code. There wouldn't be any problem if people were able to use tabs for indentation and spaces for alignment, i.e. in cases like if (cond1 && cond2) But people are dumb and many project leaders "take no risks" and require spaces everywhere instead of doing it properly. An ever better solution is elastic tabstops, but unfortunately no major editor supports that.
Re: indent style for D
On Sunday, 29 January 2012 at 14:42:16 UTC, Daniel Murphy wrote: http://media.comicvine.com/uploads/6/67698/1595201-oh_look_its_this_thread_again_super.jpg That's nothing. If you want to see a truly great bikeshedding thread, go there: http://www.reddit.com/r/programming/comments/p1j1c/tabs_vs_spaces_vs_both/
Re: indent style for D
Personally, I've never understood how anyone can stand anything other than Allman. Totally agree.
Re: indent style for D
Le 29/01/2012 12:36, Trass3r a écrit : http://www.d-programming-language.org/dstyle.html in regard to indent-style, can someone shed some light what is recommended practice for it within D community? Everyone thinks his way is the best. I would say that the most important is to be consistent accros a project or a code base. The style in itself, execpt for some special tricky case doesn't change a lot.
Re: indent style for D
http://media.comicvine.com/uploads/6/67698/1595201-oh_look_its_this_thread_again_super.jpg
Re: indent style for D
Denis Shelomovskij: > Am I mistaken? If no, am I missing some major spaces advantages? If no, > lets use tabs. D2 style guide should *require* D2 to be edited using a mono-spaced font, and the D2 front-end should enforce this with a "-ms" compiler switch. Bye, bearophile
Re: indent style for D
On 29 January 2012 14:04, Denis Shelomovskij wrote: > 29.01.2012 15:21, Alex Rønne Petersen пишет: > >> On 29-01-2012 10:15, Gour wrote: >>> >>> Hello! >>> >>> It was mentioned in #D that gdc will probably adapt its code to GNU code >>> style and I wonder, seeing no recemmendation in >>> http://www.d-programming-language.org/dstyle.html in regard to >>> indent-style, can someone shed some light what is recommended practice >>> for it within D community? >>> >>> >>> Sincerely, >>> Gour >>> >> >> Phobos generally uses 4-space indentation. >> > > I don't think there is the best coding style (personally I like both K&R and > Allman styles). IMHO things are different with indention. Why does Phobos > use 4-space indentation? > > The following article (IMHO) completely covers tabs vs spaces problem: > http://www.emacswiki.org/cgi-bin/wiki/TabsAreEvil > > It shows that tabs (in spite of the article title) are really good and > should be used always (and only) for indention. Looks like Allman style > doesn't prevent this (if it does, what is the reason?). So: > * Such tab using shows respect to a programmer allowing him to configure tab > size as he prefer. > * Sometimes indention should be changed for a particular using. > * Worst of all, sometimes same code is used in different places where > different indention levels are expected. > * Using spaces guarantee that code will look same in every editor but it is > the simplest and not the most convenient way, the code should look _good for > every editor user_, not _same_, so it tears down our community. > * It's less comfortable to use spaces for indention in every editor I use > (at least because spaces allows caret position in the middle of indention > and pressing deletes one space instead of the > indention level, so it's easy to accidentally broke indention and use, e.g. > 7 instead of 8 spaces). > > And this isn't only a theory. In practice: > * I've never liked 8-chars indention, so I feels myself bad in d-p-l.org > sources. Probably I'm not the only one. > * I accidentally brake spaces indention sometimes. Probably I'm not the > less-trained-in-printing one. > * Some time ago a ebook version of d-p-l.org has been created. Walter had to > change every 4-spaces indention in examples to 2-spaces indention for > convenience reading on small PPC screen. > * Now everyone see 2-spaces indented examples in d-p-l.org instead of his, > probably, preferred 4-spaces indented. > > Am I mistaken? If no, am I missing some major spaces advantages? If no, lets > use tabs. Perhaps, there is no tool that will convert (convert right, not > somehow, see article) tabs<->spaces in D code. The problem is lines with mixed tabs and spaces, and different users set their text editors see tabs differently. ie: is your tab-width set to 2, 3, 4, or 8? -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Re: indent style for D
29.01.2012 15:21, Alex Rønne Petersen пишет: On 29-01-2012 10:15, Gour wrote: Hello! It was mentioned in #D that gdc will probably adapt its code to GNU code style and I wonder, seeing no recemmendation in http://www.d-programming-language.org/dstyle.html in regard to indent-style, can someone shed some light what is recommended practice for it within D community? Sincerely, Gour Phobos generally uses 4-space indentation. I don't think there is the best coding style (personally I like both K&R and Allman styles). IMHO things are different with indention. Why does Phobos use 4-space indentation? The following article (IMHO) completely covers tabs vs spaces problem: http://www.emacswiki.org/cgi-bin/wiki/TabsAreEvil It shows that tabs (in spite of the article title) are really good and should be used always (and only) for indention. Looks like Allman style doesn't prevent this (if it does, what is the reason?). So: * Such tab using shows respect to a programmer allowing him to configure tab size as he prefer. * Sometimes indention should be changed for a particular using. * Worst of all, sometimes same code is used in different places where different indention levels are expected. * Using spaces guarantee that code will look same in every editor but it is the simplest and not the most convenient way, the code should look _good for every editor user_, not _same_, so it tears down our community. * It's less comfortable to use spaces for indention in every editor I use (at least because spaces allows caret position in the middle of indention and pressing deletes one space instead of the indention level, so it's easy to accidentally broke indention and use, e.g. 7 instead of 8 spaces). And this isn't only a theory. In practice: * I've never liked 8-chars indention, so I feels myself bad in d-p-l.org sources. Probably I'm not the only one. * I accidentally brake spaces indention sometimes. Probably I'm not the less-trained-in-printing one. * Some time ago a ebook version of d-p-l.org has been created. Walter had to change every 4-spaces indention in examples to 2-spaces indention for convenience reading on small PPC screen. * Now everyone see 2-spaces indented examples in d-p-l.org instead of his, probably, preferred 4-spaces indented. Am I mistaken? If no, am I missing some major spaces advantages? If no, lets use tabs. Perhaps, there is no tool that will convert (convert right, not somehow, see article) tabs<->spaces in D code.
Re: indent style for D
On Sunday, January 29, 2012 12:34:22 Gour wrote: > On Sun, 29 Jan 2012 12:21:35 +0100 > > Alex Rønne Petersen wrote: > > Phobos generally uses 4-space indentation. > > That is mentioned in the style-guide, but I'm curious about bracing, > iow, GNUstyle, K&R, ANSI...? Phobos uses Allman: http://en.wikipedia.org/wiki/Indent_style#Allman_style But everyone is free to format their code how they like. Personally, I've never understood how anyone can stand anything other than Allman, but to each their own, I suppose. - Jonathan M Davis
Re: indent style for D
http://www.d-programming-language.org/dstyle.html in regard to indent-style, can someone shed some light what is recommended practice for it within D community? Everyone thinks his way is the best.
Re: indent style for D
Am 29.01.2012, 12:34 Uhr, schrieb Gour : On Sun, 29 Jan 2012 12:21:35 +0100 Alex Rønne Petersen wrote: Phobos generally uses 4-space indentation. That is mentioned in the style-guide, but I'm curious about bracing, iow, GNUstyle, K&R, ANSI...? Some people seem to use that godawful BSD KNF style. But I've also seen lots of Allman (ANSI)-style code.
Re: indent style for D
On Sun, 29 Jan 2012 12:21:35 +0100 Alex Rønne Petersen wrote: > Phobos generally uses 4-space indentation. That is mentioned in the style-guide, but I'm curious about bracing, iow, GNUstyle, K&R, ANSI...? Sincerely, Gour -- The working senses are superior to dull matter; mind is higher than the senses; intelligence is still higher than the mind; and he [the soul] is even higher than the intelligence. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
Re: indent style for D
On 29-01-2012 10:15, Gour wrote: Hello! It was mentioned in #D that gdc will probably adapt its code to GNU code style and I wonder, seeing no recemmendation in http://www.d-programming-language.org/dstyle.html in regard to indent-style, can someone shed some light what is recommended practice for it within D community? Sincerely, Gour Phobos generally uses 4-space indentation. -- - Alex
Re: indent style for D
On Sunday, January 29, 2012 10:15:25 Gour wrote: > Hello! > > It was mentioned in #D that gdc will probably adapt its code to GNU code > style and I wonder, seeing no recemmendation in > http://www.d-programming-language.org/dstyle.html in regard to > indent-style, can someone shed some light what is recommended practice > for it within D community? What about it? That page clearly says no tabs and that each indentation level is 4 spaces. What else do you want to know? In Phobos braces, go on their own line (the D style page does need to be updated with that information), but that's not necessarily the practice of the community at large. So, if _that's_ what you're looking for in terms of indentation information, there you go. But I really don't know what you'd want to know beyond the number of spaces to indent and whether to use tabs when you ask about indentation style. - Jonathan M Davis
indent style for D
Hello! It was mentioned in #D that gdc will probably adapt its code to GNU code style and I wonder, seeing no recemmendation in http://www.d-programming-language.org/dstyle.html in regard to indent-style, can someone shed some light what is recommended practice for it within D community? Sincerely, Gour -- What is night for all beings is the time of awakening for the self-controlled; and the time of awakening for all beings is night for the introspective sage. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
