Lobster game programming language


that is so if thing are lined up (be it in comment diagrams, variable assignments, or whatever).
Tabs are meant for indenting, spaces for alignment. You're allowed to mix them in that case.

/t/tfunction(variable,
/t/t variable,
/t/t variable)And it'll always line up regardless of what tab spacing you use. If you like indents to be 4 characters it'll work. If you're from a culture that hates the number 4 and all indents are to be 3 you're good. Anyone can look at your code and be comfortable with the tab alignment.The instant one person replaces a tab with a fixed number of spaces, however, or a fixed number of spaces with a tab, the whole thing gets shot and you are now forced to use that tab width.

The code I'm currently working with consists of a library that used 4 spaces to indent and replaced 8 spaces with a tab and one that uses 3 spaces to indent replacing 4 spaces with a tab. It is a headache to quickly look from one file to another.

Tabs are for indenting, spaces are for alignment. This is the only way to make everyone happy.
 
@WizardStan: Saying everyone would be happy using spaces for alignment obviously isn't true given it has been stated software houes already use tab only, they wouldn't be happy changing.

And when lining stuff up at the end of line, I don't see how spaces solve anything:
 
Tab width : 4


if ( some_condition_that_goes_on_for_quite_a_long_time( ) ) // This comment lines up with
{ // this line. I have only used
ThisLineIsTabbedIn( ); // space bar to line up comments
} // but will line 3 'line up'
// with tab width set to 8?

Tab width : 8

Code:
if ( some_condition_that_goes_on_for_quite_a_long_time( ) )  // This comment lines up with
{                                                            // this line
        ThisLineIsTabbedIn( );                                   // I have only used space bar
}                                                            // but will line 3 'line up'
                                                             // with tab width set to 8?
 
#define macro *something*


if ( poof )


  macro;


where *something* is >1 line.
When you say more than one line, I guess you are talking about multiple lines with continuation characters at the end, e.g.


#define macro \
CheckStack( ); \
CheckHeap( ); \
DumpResults( )

if ( poof )
macro;

In the above, what do you find the biggest problem to be (the fact it can be deceptive, doesn't even look like a function yet calls three functions, or maybe the fact when debugging you can't set a breakpoint inside the macro, or perhaps something else?).

I am curious; I would certainly not write code quite like that, but interesting to know the various pitfalls you have seen with this sort of code over the years. I don't find this overly offensive:


#define CheckStuff( ) \
do \
{ \
int hr = CheckSomething( ); \
if ( hr != 0 ) \
{ \
printf( "Check failed [code %d] in %s(%d)", hr, __FUNCTION__, __LINE__ ); \
} \
} \
while ( 0 )

// Build matrices from input data.
BuildMatrcies( );

// Ensure no bad data has been fed into us
CheckStuff( );

It isn't a real example I've written or anything, but getting __FUNCTION__ and __LINE__ from macro's can lead to helpful debugging systems, the macro can be used just to forward these onto a proper function too of course.
 
Last edited by a moderator:
Saying everyone would be happy using spaces for alignment obviously isn't true given it has been stated software houes already use tab only, they wouldn't be happy changing
Maybe they wouldn't be happy during the switch but it'd work out better after the switch and would simply serve as a reminder that if they'd done it right the first time they wouldn't have to switch.
And when lining stuff up at the end of line, I don't see how spaces solve anything
Using end of line comments is an entirely different problem. :P
 
@WizardStan end of line comments, or variable alignments (that might be towards end of line) are a couple of the obvious use cases why studios often have tab width set in the coding standard. This is also the reason why your suggestion in post #21 simply doesn't work (essentially saying you can ignore the size of a tab providing you follow your rule of using spaces for alignment). This isn't so much me expressing my personal opinion, as me reflecting on how code standards have come about at a few places I've dealt with. The only way your rule works if you start interfering further and stipulating extra conditions (never line anything up on the right after a single tab has been used before it, which to me is a bit of a weird rule, not one I've personally ever come across).

My opinion remains the same, coding guideline sets tab width, coding guideline sets tabs vs spacing policy. The first is required to allow alignment to be correct for everyone, the second will just about always be tabs for a C/C++ language for indentation, and the choice of space vs tab for alignment is up in the air, no real difference either way (although tab is less key presses, and is uniform with what is used everywhere else, so is probably my preference).

That said, if you were my employer and you said, 'Steven, at this studio these are the guidelines you must follow' in that sense you would be 'right', and I would indeed follow your standard!

I used to do a lot of VU coding for the PS2, for that you write two instructions per line (one on the floating pipeline, one on the integer pipeline), and often two set of comments too, and I can tell you in this case having to use spaces for alignment would have been a nightmare! Honestly, I'd be surprised if you had personally dealt with these scenarios and still support your stance.
 
Last edited by a moderator:
interesting discussion... I'm a programmer and at work we never set rules for this type of things, anyway seems like the code is always readable and no one ever complained about how to indent, so seems like I'm in a lucky situation
 
I think it depends on the projects workflow. If you have a real 'patch and release manager' (like Linus) than this person will typically enforce (simply by ignoring substandard patches) various (mostly arbitrary, but that is not a neccessarily a bad thing) rules to make his/her work easier. In typical corporate projects where everybody has their own personal area and just pushes their crap to the central repo, it is more chaotic (but still works reasonably well even with bad management). And then there are the projects run according to the hype method of the day. These have lots of funny (and arbitrary) rules, but their success is actually completely independent of the method and rules employed and solely depends on the competence level of the project manager (there actually are amazingly good managers out there, unfortunately it is a small minority).
 
Futurama-futurama-606040_640_480.gif


My thoughts on LGPL
 
Last edited by a moderator:
That image seems broken...  

you might also want to rethink use of  that acronym..  I thought you were referring to something else until I reread the thread title. ;)

- Neelix
 
Back
Top