Thanks for your offer of help NEX9. At present my art needs are pretty limited. I really only needed a few sprites here and there to get the theme of the game sorted in my mind, to make it easier for other people to pick up on it. Tycho came forward first with some basic planets that we improved through a number of revisions to come up with something that I thought looked good.
Now that that's done there's little else that I could really put any amount of artists to work on. If you feel like checking on this thread later and seeing if there's anything I need done, that'd be great.
ThansalThe New ScumJoin Date: 2002-08-22Member: 1215Members, Constellation
<!--quoteo(post=1655078:date=Oct 10 2007, 09:29 AM:name=NeonSpyder)--><div class='quotetop'>QUOTE(NeonSpyder @ Oct 10 2007, 09:29 AM) <a href="index.php?act=findpost&pid=1655078"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->My hard-drive is very broken, and it sucks.<!--QuoteEnd--></div><!--QuoteEEnd--> 5-7-5 not 4-5-3(4?)
My hard drive is, incredibly broken now, it sucks the big one.
So I've written another post on my <a href="http://www.tjhowse.com/forums/index.php?showtopic=83" target="_blank">development blouge</a> for USG. I go on a bit about how I'm now procedurally generating the maps for the villages, cities, bases and space stations for my game. There's also a version of the generator you can download and play at home! Endless entertainment! Mickey mouse shaped houses! Penis shaped houses! Incredible!
Why do you have to call it a development bloosh? Can't you call it something other than a development bloosh? Anything other than a development bloosh?
<!--quoteo(post=1667226:date=Jan 12 2008, 12:11 PM:name=lolfighter)--><div class='quotetop'>QUOTE(lolfighter @ Jan 12 2008, 12:11 PM) <a href="index.php?act=findpost&pid=1667226"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Why do you have to call it a development bloosh? Can't you call it something other than a development bloosh? Anything other than a development bloosh?<!--QuoteEnd--></div><!--QuoteEEnd-->
How unquie are those planets exactly? <img src="style_emoticons/<#EMO_DIR#>/tounge.gif" style="vertical-align:middle" emoid=":p" border="0" alt="tounge.gif" />
Check out the top right house <img src="style_emoticons/<#EMO_DIR#>/biggrin-fix.gif" style="vertical-align:middle" emoid=":D" border="0" alt="biggrin-fix.gif" />
So I've recently complete a fairly huge chunk of work, bringing USG damn close to playable. There aren't any NPCs or usable weapons, but there is some pretty awesome stuff. I've shown off quite a bit of the stuff I've been working on recently, as well as showing my process for planning out chunks of work.
<a href="http://www.tjhowse.com/forums/index.php?showtopic=87" target="_blank">Clicklah teh linkzor.</a>
I've written a bit of code that imports LUA files into the game as weapon components. Custom components ahoy!
--Scythe--
P.S. Please take some time to savour that topic descriptor. I thought it was particularly delicious.<!--QuoteEnd--></div><!--QuoteEEnd--> <!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1--> outsig1 = "" outsig2 = "" outsig3 = "" outsig4 = "" outsig5 = "" outsig6 = "" outsig7 = "" outsig8 = ""<!--c2--></div><!--ec2--> could be rewritten as <!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1--> outsig1,outsig2,outsig3,outsig4,outsig5,outsig6,outsig7,outsig8 = "","","","","","","",""<!--c2--></div><!--ec2--> It's a bit denser, but then again all you're doing is initializing all those variables.
NOTE: the line break was caused by the forums, and should not be there if you want lua to actually work.
remiremedy [blu.knight]Join Date: 2003-11-18Member: 23112Members, Super Administrators, Forum Admins, NS2 Developer, NS2 Playtester
edited February 2009
<!--quoteo(post=1699846:date=Feb 9 2009, 10:33 AM:name=lolfighter)--><div class='quotetop'>QUOTE(lolfighter @ Feb 9 2009, 10:33 AM) <a href="index.php?act=findpost&pid=1699846"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->There doesn't seem to be any practical difference between the two though. I'd go with whatever I find more natural.<!--QuoteEnd--></div><!--QuoteEEnd-->
<u>Practical Differences:</u> 1. The first is less prone to error.
LUA doesn't care if you do <!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->a,b,c = 1<!--c2--></div><!--ec2--> or <!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->a = 1,2,3<!--c2--></div><!--ec2--> With the first, it will ignore b and c, with the second it will ignore the 2 and 3. No error is thrown.
2. The second saves vertical space.
The function of those lines is merely to initialize all those variables to be empty. Some might argue that putting it all on one line makes it harder to read, but I think that because they are all executing the same very simple function, it is a good idea to have it all on the same line.
Initializing the variables is a pretty common thing to do, and doesn't really have anything to do with the logic of the function... I like the important aspects of the logic to take the real estate. Not the repetitive things.
I find it amazing that such a discussion emerged on the topic of writing style. Although I will admit that the old c-style and now java style of curly brace handling can get me heated.
if( ) {
}
is SO much less readable than
if( ) {
}
Who cares about saving white space these days? Hard drives are cheap and it all gets compiled out anyway!
remiremedy [blu.knight]Join Date: 2003-11-18Member: 23112Members, Super Administrators, Forum Admins, NS2 Developer, NS2 Playtester
edited February 2009
<!--quoteo(post=1699867:date=Feb 9 2009, 03:32 PM:name=Rob)--><div class='quotetop'>QUOTE(Rob @ Feb 9 2009, 03:32 PM) <a href="index.php?act=findpost&pid=1699867"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->is SO much less readable than<!--QuoteEnd--></div><!--QuoteEEnd--> This is most definitely your opinion, and not a fact. It is fact that the first saves vertical space.
I find the first easier to read with if statements and loops because the code that the if statement affects isn't separated by an extra line; though I have began to use the second method to wrap the whole function.
I sort of implied this, but the point of saving vertical space is not to get a smaller file size. It is to keep all the related code closer together so less scrolling is needed to see the logic. I use white space to separate as necessary for readability. I don't think putting the { on a separate line increases readability. It just wastes vertical space.
Looks like I hit a nerve. <img src="style_emoticons/<#EMO_DIR#>/smile-fix.gif" style="vertical-align:middle" emoid=":)" border="0" alt="smile-fix.gif" />
The line between logic code and mundane code isn't so clear to me, and I find it more important to be able to line up code sections. It's really important in a language like C where curly's mean something for scope. It also helps out to make sure every open has a close and also to keep full statements in line. For instance:
if () statement;
vs
if () { statement; }
Even at the cost of vertical space, you most often see the second version, and though they're equivalent, it takes some getting used to to quickly accept the difference. I find myself having to stop reading the code and stare at the first one for awhile until I figure out what it means.
remiremedy [blu.knight]Join Date: 2003-11-18Member: 23112Members, Super Administrators, Forum Admins, NS2 Developer, NS2 Playtester
<!--quoteo(post=1699880:date=Feb 9 2009, 05:51 PM:name=Rob)--><div class='quotetop'>QUOTE(Rob @ Feb 9 2009, 05:51 PM) <a href="index.php?act=findpost&pid=1699880"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->But I digress before I derail the thread.<!--QuoteEnd--></div><!--QuoteEEnd--> It's too late for that. <img src="style_emoticons/<#EMO_DIR#>/tounge.gif" style="vertical-align:middle" emoid=":p" border="0" alt="tounge.gif" />
<!--quoteo--><div class='quotetop'>QUOTE</div><div class='quotemain'><!--quotec-->Looks like I hit a nerve. <img src="style_emoticons/<#EMO_DIR#>/smile-fix.gif" style="vertical-align:middle" emoid=":)" border="0" alt="smile-fix.gif" /><!--QuoteEnd--></div><!--QuoteEEnd--> Ah, from your previous response I thought I had hit one of yours. <img src="style_emoticons/<#EMO_DIR#>/smile-fix.gif" style="vertical-align:middle" emoid=":)" border="0" alt="smile-fix.gif" />
<!--quoteo--><div class='quotetop'>QUOTE</div><div class='quotemain'><!--quotec-->The line between logic code and mundane code isn't so clear to me, and I find it more important to be able to line up code sections. It's really important in a language like C where curly's mean something for scope. It also helps out to make sure every open has a close and also to keep full statements in line. For instance:
if () statement;
vs
if () { statement; }
Even at the cost of vertical space, you most often see the second version, and though they're equivalent, it takes some getting used to to quickly accept the difference. I find myself having to stop reading the code and stare at the first one for awhile until I figure out what it means.<!--QuoteEnd--></div><!--QuoteEEnd-->
The first one I almost never do. The second I do quite often in this situation: <!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->if (!variable) return;<!--c2--></div><!--ec2-->
The whole thing just comes down to my preference for saving vertical space. I've used the { on the same line for the last 8 years, so I can read code quickly that is formatted that way. I actually get hung up on simple if statements with the other formatting, the same way you do with the same-line open bracket.
What do you think of this kind of formatting? (Horstmann style) <!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->if (this_is_true) { functioncall(); something = else; return true; }<!--c2--></div><!--ec2-->
It's kind of neat, and I think it combines the advantages of both our formats. Looks so alien to me though, it's even harder for me to read than your way.
Apparently, my way of putting the { on a seperate line only for the function declaration, yet on a same line for everything else is K&R style. Yours is called Allman style.
Also, this is a neat little blurb from the wiki article ( <a href="http://en.wikipedia.org/wiki/Indent_style" target="_blank">http://en.wikipedia.org/wiki/Indent_style</a> ) <!--quoteo--><div class='quotetop'>QUOTE</div><div class='quotemain'><!--quotec-->Programmers who rely on counting the opening braces may have difficulty with indentation styles such as K&R, where the beginning brace is not visually separated from its control statement. Programmers who rely more on indentation will gain more from styles that are vertically compact, such as K&R, because the blocks are shorter.<!--QuoteEnd--></div><!--QuoteEEnd-->
I think I might try using Horstmann style. It seems slightly alien, but it does combine the advantages of both our styles.
I don't have a problem reading the Horstmann style, but my copy/paste fanaticism would probably suffer if I used it: I would be copying that open bracket all the time by accident.
And I wholly agree with the quote from wikipedia you posted. I have a terrible time with python, what with it wanting <i>spaces</i> instead of tabs and using indenting the way it does. It's witchcraft, I tell you. For me, white space delimiting major blocks of code is essential; otherwise, my eyes get lost in what looks like an endless wall of text. I try to group together statements into discrete chunks that are closely related. Like paragraphs, I suppose.
Also, I seem to leave extra spaces in between the parenthesis of embedded function calls, but I'm pretty sure this is just something that happens occasionally as I type. <img src="style_emoticons/<#EMO_DIR#>/tounge.gif" style="vertical-align:middle" emoid=":p" border="0" alt="tounge.gif" /> Anyway, I tend to start with initialization of an object, then have the object do work, then leave a blank line, if that makes any sense.
remiremedy [blu.knight]Join Date: 2003-11-18Member: 23112Members, Super Administrators, Forum Admins, NS2 Developer, NS2 Playtester
edited February 2009
<!--quoteo(post=1699892:date=Feb 9 2009, 07:59 PM:name=Rob)--><div class='quotetop'>QUOTE(Rob @ Feb 9 2009, 07:59 PM) <a href="index.php?act=findpost&pid=1699892"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I don't have a problem reading the Horstmann style, but my copy/paste fanaticism would probably suffer if I used it: I would be copying that open bracket all the time by accident.<!--QuoteEnd--></div><!--QuoteEEnd--> That's a pretty good point. Curious if it's a valid point though. Might very well be... On the other hand, indent is normally screwed up anyways with the copy-pasta.
<!--quoteo--><div class='quotetop'>QUOTE</div><div class='quotemain'><!--quotec-->I try to group together statements into discrete chunks that are closely related. Like paragraphs, I suppose.<!--QuoteEnd--></div><!--QuoteEEnd--> I feel the same way, that's why I like my logic (if statements) to not be seperated from the code it controls.
<!--quoteo--><div class='quotetop'>QUOTE</div><div class='quotemain'><!--quotec-->Also, I seem to leave extra spaces in between the parenthesis of embedded function calls, but I'm pretty sure this is just something that happens occasionally as I type. <img src="style_emoticons/<#EMO_DIR#>/tounge.gif" style="vertical-align:middle" emoid=":p" border="0" alt="tounge.gif" /> Anyway, I tend to start with initialization of an object, then have the object do work, then leave a blank line, if that makes any sense.<!--QuoteEnd--></div><!--QuoteEEnd--> I think we both appreciate clean pretty code, and only differ on the curly brace placement. <img src="style_emoticons/<#EMO_DIR#>/smile-fix.gif" style="vertical-align:middle" emoid=":)" border="0" alt="smile-fix.gif" />
Now, we could either cut off this discussion (which I found quite entertaining) or we could talk about hungarian notation! Hehe.. (Though that is a less controversial issue)
Cool, I check your blogue every couple weeks. Looking forward to play USG someday. <img src="style_emoticons/<#EMO_DIR#>/wink-fix.gif" style="vertical-align:middle" emoid=";)" border="0" alt="wink-fix.gif" />
One thing though - are insig1, insig2, ... generic signals or does each of them stand for a specific action? Because if so, you might want to rename them to ammo_sig, damage_sig, and so on to avoid confusion.
<!--quoteo(post=1699908:date=Feb 10 2009, 04:55 PM:name=Razagal)--><div class='quotetop'>QUOTE(Razagal @ Feb 10 2009, 04:55 PM) <a href="index.php?act=findpost&pid=1699908"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Cool, I check your blogue every couple weeks. Looking forward to play USG someday. <img src="style_emoticons/<#EMO_DIR#>/wink-fix.gif" style="vertical-align:middle" emoid=";)" border="0" alt="wink-fix.gif" />
One thing though - are insig1, insig2, ... generic signals or does each of them stand for a specific action? Because if so, you might want to rename them to ammo_sig, damage_sig, and so on to avoid confusion.<!--QuoteEnd--></div><!--QuoteEEnd-->
The ports do not have a specific function on all components, it depends on the component in question. The ports are enumerated thusly in an eight-port device:
In a four-port device the sides will be numbered in the same order, but just 1-4. Having said that, the overarching C++ program doesn't care about the variable names, only the datatypes being handed in and out. It's entirely possible for someone writing a LUA script for a component to give the in and out signals whatever names they want, provided they always transmit and receive exactly eight in the signal() function.
To answer your question: No, I won't specify a template including specific descriptors for each signal port, but it's entirely possible to name them whatever you want.
If by Hungarian, you mean the use of a prefix on variable names to indicate type and usage, then I think it's a question of project scale and the IDE involved. In a small project, it doesn't help much. In a smart IDE like eclipse or Visual Studio, all you have to do is hover over the variable and it'll give you the type, and from that you should be smart enough to figure out what it means.
But if you're modifying code in a project that has several thousand lines of code and it's in a language like c++ and it's hard as hell to figure out where the hell a variable has been declared when you're looking at it (the HLSDK or Source SDK comes to mind...), then it can be a real life saver.
That said, I don't think I'd ever use the whole thing. But I take some of the core ideas. m_ prefix for member variables (or just a single underscore, as my company coding standards say...).
@Scythe (to keep at least one wheel on the track, here)
I think your concept of a component with input and output signals is neat, and very flexible. I fear, though, that using strings that way will become difficult to manage. For instance, is there a difference between "W9MM" and "w9MM"? Free form strings allow for a lot of latitude, but can become a real mess, especially during maintenance. If I'm wrong here and these are not strings so much as constants that can be passed in and how, then ignore me.
If by Hungarian, you mean the use of a prefix on variable names to indicate type and usage, then I think it's a question of project scale and the IDE involved. In a small project, it doesn't help much. In a smart IDE like eclipse or Visual Studio, all you have to do is hover over the variable and it'll give you the type, and from that you should be smart enough to figure out what it means.
But if you're modifying code in a project that has several thousand lines of code and it's in a language like c++ and it's hard as hell to figure out where the hell a variable has been declared when you're looking at it (the HLSDK or Source SDK comes to mind...), then it can be a real life saver.
That said, I don't think I'd ever use the whole thing. But I take some of the core ideas. m_ prefix for member variables (or just a single underscore, as my company coding standards say...).<!--QuoteEnd--></div><!--QuoteEEnd--> Yup, there's very little debate on this one. Personally I like using m_ (member variable), b (boolean), and p (pointer). The rest of them seem like a waste of time and make refactoring more difficult (because if you change a variables type you need to change every reference to it).
The Source SDK... I have mixed feelings on this. I do like having the extra information available but it really goes against the whole concept of only needing to change things in 1 place... There are some examples on the wiki of how hungarian can get very bad... e.g. a_crszkvc30LastNameCol While working on my mod, I tend to follow Hungarian while working with member variables (especially networked ones)... e.g. m_fAstralDuration In functions, I only use b and p because the declarations are right there. pEnt is much better than entptr, and I like marking my flags as such. (Boolean variables rarely change type, so that's less of an issue)
It's strange your company uses _ for member variables, as that is reserved for local variables in hungarian syntax (though this aspect doesn't seem to be followed in the the Source SDK)
<!--quoteo--><div class='quotetop'>QUOTE</div><div class='quotemain'><!--quotec-->@Scythe (to keep at least one wheel on the track, here) .... If I'm wrong here and these are not strings<!--QuoteEnd--></div><!--QuoteEEnd--> If I remember correctly, LUA is very promiscuous. There is no type to the variables, you can put whatever you want in them. It comes down to how Scythe handles it in the C++ side of things.
remiremedy [blu.knight]Join Date: 2003-11-18Member: 23112Members, Super Administrators, Forum Admins, NS2 Developer, NS2 Playtester
edited February 2009
<!--quoteo(post=1699935:date=Feb 10 2009, 10:52 AM:name=lolfighter)--><div class='quotetop'>QUOTE(lolfighter @ Feb 10 2009, 10:52 AM) <a href="index.php?act=findpost&pid=1699935"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Since we're talking about nationalities, how about that polish notation? Awesome or what?<!--QuoteEnd--></div><!--QuoteEEnd--> I have this friend back home that is really tall and lanky, so I call him a pole. He gets annoyed with me. He is also polish.
Comments
Now that that's done there's little else that I could really put any amount of artists to work on. If you feel like checking on this thread later and seeing if there's anything I need done, that'd be great.
--Scythe--
is very broken,
and it sucks.<!--QuoteEnd--></div><!--QuoteEEnd-->
5-7-5 not 4-5-3(4?)
My hard drive is,
incredibly broken now,
it sucks the big one.
My hard drive is,
incredibly broken now,
it sucks the big one.<!--QuoteEnd--></div><!--QuoteEEnd-->
How do you pronounce hard-drive that it has 3 syllables?
Mine is 3-5-3
**edit
Oh wait. Depends how strong a 'v' you give it. Ahem, yes. I blame it on the lack of hard-drive that made me screw that up.
GRAAAAGGHHHH. THREAD LIVE.
So I've written another post on my <a href="http://www.tjhowse.com/forums/index.php?showtopic=83" target="_blank">development blouge</a> for USG. I go on a bit about how I'm now procedurally generating the maps for the villages, cities, bases and space stations for my game. There's also a version of the generator you can download and play at home! Endless entertainment! Mickey mouse shaped houses! Penis shaped houses! Incredible!
--Scythe--
It's more of a blooj.
Okay, that was a low blow. I'm sorry.
Check out the top right house <img src="style_emoticons/<#EMO_DIR#>/biggrin-fix.gif" style="vertical-align:middle" emoid=":D" border="0" alt="biggrin-fix.gif" />
So I've recently complete a fairly huge chunk of work, bringing USG damn close to playable. There aren't any NPCs or usable weapons, but there is some pretty awesome stuff. I've shown off quite a bit of the stuff I've been working on recently, as well as showing my process for planning out chunks of work.
<a href="http://www.tjhowse.com/forums/index.php?showtopic=87" target="_blank">Clicklah teh linkzor.</a>
--Scythe--
</idiotspeak>
Pretty neat Scythe <img src="style_emoticons/<#EMO_DIR#>/biggrin-fix.gif" style="vertical-align:middle" emoid=":D" border="0" alt="biggrin-fix.gif" />
<a href="http://www.tjhowse.com/forums/index.php?showtopic=94" target="_blank">A hyperlink!</a>
I've written a bit of code that imports LUA files into the game as weapon components. Custom components ahoy!
--Scythe--
P.S. Please take some time to savour that topic descriptor. I thought it was particularly delicious.
I've written a bit of code that imports LUA files into the game as weapon components. Custom components ahoy!
--Scythe--
P.S. Please take some time to savour that topic descriptor. I thought it was particularly delicious.<!--QuoteEnd--></div><!--QuoteEEnd-->
<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1--> outsig1 = ""
outsig2 = ""
outsig3 = ""
outsig4 = ""
outsig5 = ""
outsig6 = ""
outsig7 = ""
outsig8 = ""<!--c2--></div><!--ec2-->
could be rewritten as
<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1--> outsig1,outsig2,outsig3,outsig4,outsig5,outsig6,outsig7,outsig8 = "","","","","","","",""<!--c2--></div><!--ec2-->
It's a bit denser, but then again all you're doing is initializing all those variables.
NOTE: the line break was caused by the forums, and should not be there if you want lua to actually work.
<u>Practical Differences:</u>
1. The first is less prone to error.
LUA doesn't care if you do
<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->a,b,c = 1<!--c2--></div><!--ec2-->
or
<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->a = 1,2,3<!--c2--></div><!--ec2-->
With the first, it will ignore b and c, with the second it will ignore the 2 and 3. No error is thrown.
2. The second saves vertical space.
The function of those lines is merely to initialize all those variables to be empty.
Some might argue that putting it all on one line makes it harder to read, but I think that because they are all executing the same very simple function, it is a good idea to have it all on the same line.
Initializing the variables is a pretty common thing to do, and doesn't really have anything to do with the logic of the function... I like the important aspects of the logic to take the real estate. Not the repetitive things.
if( ) {
}
is SO much less readable than
if( )
{
}
Who cares about saving white space these days? Hard drives are cheap and it all gets compiled out anyway!
This is most definitely your opinion, and not a fact.
It is fact that the first saves vertical space.
I find the first easier to read with if statements and loops because the code that the if statement affects isn't separated by an extra line; though I have began to use the second method to wrap the whole function.
I sort of implied this, but the point of saving vertical space is not to get a smaller file size. It is to keep all the related code closer together so less scrolling is needed to see the logic. I use white space to separate as necessary for readability. I don't think putting the { on a separate line increases readability. It just wastes vertical space.
The line between logic code and mundane code isn't so clear to me, and I find it more important to be able to line up code sections. It's really important in a language like C where curly's mean something for scope. It also helps out to make sure every open has a close and also to keep full statements in line. For instance:
if () statement;
vs
if ()
{
statement;
}
Even at the cost of vertical space, you most often see the second version, and though they're equivalent, it takes some getting used to to quickly accept the difference. I find myself having to stop reading the code and stare at the first one for awhile until I figure out what it means.
But I digress before I derail the thread.
It's too late for that. <img src="style_emoticons/<#EMO_DIR#>/tounge.gif" style="vertical-align:middle" emoid=":p" border="0" alt="tounge.gif" />
<!--quoteo--><div class='quotetop'>QUOTE</div><div class='quotemain'><!--quotec-->Looks like I hit a nerve. <img src="style_emoticons/<#EMO_DIR#>/smile-fix.gif" style="vertical-align:middle" emoid=":)" border="0" alt="smile-fix.gif" /><!--QuoteEnd--></div><!--QuoteEEnd-->
Ah, from your previous response I thought I had hit one of yours. <img src="style_emoticons/<#EMO_DIR#>/smile-fix.gif" style="vertical-align:middle" emoid=":)" border="0" alt="smile-fix.gif" />
<!--quoteo--><div class='quotetop'>QUOTE</div><div class='quotemain'><!--quotec-->The line between logic code and mundane code isn't so clear to me, and I find it more important to be able to line up code sections. It's really important in a language like C where curly's mean something for scope. It also helps out to make sure every open has a close and also to keep full statements in line. For instance:
if () statement;
vs
if ()
{
statement;
}
Even at the cost of vertical space, you most often see the second version, and though they're equivalent, it takes some getting used to to quickly accept the difference. I find myself having to stop reading the code and stare at the first one for awhile until I figure out what it means.<!--QuoteEnd--></div><!--QuoteEEnd-->
The first one I almost never do.
The second I do quite often in this situation:
<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->if (!variable)
return;<!--c2--></div><!--ec2-->
The whole thing just comes down to my preference for saving vertical space. I've used the { on the same line for the last 8 years, so I can read code quickly that is formatted that way. I actually get hung up on simple if statements with the other formatting, the same way you do with the same-line open bracket.
What do you think of this kind of formatting? (Horstmann style)
<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->if (this_is_true)
{ functioncall();
something = else;
return true;
}<!--c2--></div><!--ec2-->
It's kind of neat, and I think it combines the advantages of both our formats. Looks so alien to me though, it's even harder for me to read than your way.
Apparently, my way of putting the { on a seperate line only for the function declaration, yet on a same line for everything else is K&R style. Yours is called Allman style.
Also, this is a neat little blurb from the wiki article ( <a href="http://en.wikipedia.org/wiki/Indent_style" target="_blank">http://en.wikipedia.org/wiki/Indent_style</a> )
<!--quoteo--><div class='quotetop'>QUOTE</div><div class='quotemain'><!--quotec-->Programmers who rely on counting the opening braces may have difficulty with indentation styles such as K&R, where the beginning brace is not visually separated from its control statement. Programmers who rely more on indentation will gain more from styles that are vertically compact, such as K&R, because the blocks are shorter.<!--QuoteEnd--></div><!--QuoteEEnd-->
I think I might try using Horstmann style. It seems slightly alien, but it does combine the advantages of both our styles.
And I wholly agree with the quote from wikipedia you posted. I have a terrible time with python, what with it wanting <i>spaces</i> instead of tabs and using indenting the way it does. It's witchcraft, I tell you. For me, white space delimiting major blocks of code is essential; otherwise, my eyes get lost in what looks like an endless wall of text. I try to group together statements into discrete chunks that are closely related. Like paragraphs, I suppose.
For example:
<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->TcpSocket socket;
socket.setHost("127.0.0.1");
socket.setPort(7777);
if( socket.open() )
{
string str = "w00t";
socket.write( str.c_str() );
socket.close();
}<!--c2--></div><!--ec2-->
Also, I seem to leave extra spaces in between the parenthesis of embedded function calls, but I'm pretty sure this is just something that happens occasionally as I type. <img src="style_emoticons/<#EMO_DIR#>/tounge.gif" style="vertical-align:middle" emoid=":p" border="0" alt="tounge.gif" /> Anyway, I tend to start with initialization of an object, then have the object do work, then leave a blank line, if that makes any sense.
That's a pretty good point. Curious if it's a valid point though. Might very well be... On the other hand, indent is normally screwed up anyways with the copy-pasta.
<!--quoteo--><div class='quotetop'>QUOTE</div><div class='quotemain'><!--quotec-->I try to group together statements into discrete chunks that are closely related. Like paragraphs, I suppose.<!--QuoteEnd--></div><!--QuoteEEnd-->
I feel the same way, that's why I like my logic (if statements) to not be seperated from the code it controls.
<!--quoteo--><div class='quotetop'>QUOTE</div><div class='quotemain'><!--quotec-->Also, I seem to leave extra spaces in between the parenthesis of embedded function calls, but I'm pretty sure this is just something that happens occasionally as I type. <img src="style_emoticons/<#EMO_DIR#>/tounge.gif" style="vertical-align:middle" emoid=":p" border="0" alt="tounge.gif" /> Anyway, I tend to start with initialization of an object, then have the object do work, then leave a blank line, if that makes any sense.<!--QuoteEnd--></div><!--QuoteEEnd-->
I think we both appreciate clean pretty code, and only differ on the curly brace placement. <img src="style_emoticons/<#EMO_DIR#>/smile-fix.gif" style="vertical-align:middle" emoid=":)" border="0" alt="smile-fix.gif" />
Now, we could either cut off this discussion (which I found quite entertaining) or we could talk about hungarian notation! Hehe.. (Though that is a less controversial issue)
Looking forward to play USG someday. <img src="style_emoticons/<#EMO_DIR#>/wink-fix.gif" style="vertical-align:middle" emoid=";)" border="0" alt="wink-fix.gif" />
One thing though - are insig1, insig2, ... generic signals or does each of them stand for a specific action?
Because if so, you might want to rename them to ammo_sig, damage_sig, and so on to avoid confusion.
Looking forward to play USG someday. <img src="style_emoticons/<#EMO_DIR#>/wink-fix.gif" style="vertical-align:middle" emoid=";)" border="0" alt="wink-fix.gif" />
One thing though - are insig1, insig2, ... generic signals or does each of them stand for a specific action?
Because if so, you might want to rename them to ammo_sig, damage_sig, and so on to avoid confusion.<!--QuoteEnd--></div><!--QuoteEEnd-->
The ports do not have a specific function on all components, it depends on the component in question. The ports are enumerated thusly in an eight-port device:
<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1--> 1 2
-----------
8 | | 3
7 | | 4
-----------
6 5<!--c2--></div><!--ec2-->
In a four-port device the sides will be numbered in the same order, but just 1-4. Having said that, the overarching C++ program doesn't care about the variable names, only the datatypes being handed in and out. It's entirely possible for someone writing a LUA script for a component to give the in and out signals whatever names they want, provided they always transmit and receive exactly eight in the signal() function.
To answer your question: No, I won't specify a template including specific descriptors for each signal port, but it's entirely possible to name them whatever you want.
--Scythe--
P.S.
<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->loop (!woo)
{
teh_code();
}<!--c2--></div><!--ec2-->
4eva.
If by Hungarian, you mean the use of a prefix on variable names to indicate type and usage, then I think it's a question of project scale and the IDE involved. In a small project, it doesn't help much. In a smart IDE like eclipse or Visual Studio, all you have to do is hover over the variable and it'll give you the type, and from that you should be smart enough to figure out what it means.
But if you're modifying code in a project that has several thousand lines of code and it's in a language like c++ and it's hard as hell to figure out where the hell a variable has been declared when you're looking at it (the HLSDK or Source SDK comes to mind...), then it can be a real life saver.
That said, I don't think I'd ever use the whole thing. But I take some of the core ideas. m_ prefix for member variables (or just a single underscore, as my company coding standards say...).
@Scythe (to keep at least one wheel on the track, here)
I think your concept of a component with input and output signals is neat, and very flexible. I fear, though, that using strings that way will become difficult to manage. For instance, is there a difference between "W9MM" and "w9MM"? Free form strings allow for a lot of latitude, but can become a real mess, especially during maintenance. If I'm wrong here and these are not strings so much as constants that can be passed in and how, then ignore me.
If by Hungarian, you mean the use of a prefix on variable names to indicate type and usage, then I think it's a question of project scale and the IDE involved. In a small project, it doesn't help much. In a smart IDE like eclipse or Visual Studio, all you have to do is hover over the variable and it'll give you the type, and from that you should be smart enough to figure out what it means.
But if you're modifying code in a project that has several thousand lines of code and it's in a language like c++ and it's hard as hell to figure out where the hell a variable has been declared when you're looking at it (the HLSDK or Source SDK comes to mind...), then it can be a real life saver.
That said, I don't think I'd ever use the whole thing. But I take some of the core ideas. m_ prefix for member variables (or just a single underscore, as my company coding standards say...).<!--QuoteEnd--></div><!--QuoteEEnd-->
Yup, there's very little debate on this one.
Personally I like using m_ (member variable), b (boolean), and p (pointer).
The rest of them seem like a waste of time and make refactoring more difficult (because if you change a variables type you need to change every reference to it).
The Source SDK... I have mixed feelings on this. I do like having the extra information available but it really goes against the whole concept of only needing to change things in 1 place...
There are some examples on the wiki of how hungarian can get very bad... e.g. a_crszkvc30LastNameCol
While working on my mod, I tend to follow Hungarian while working with member variables (especially networked ones)... e.g. m_fAstralDuration
In functions, I only use b and p because the declarations are right there. pEnt is much better than entptr, and I like marking my flags as such. (Boolean variables rarely change type, so that's less of an issue)
It's strange your company uses _ for member variables, as that is reserved for local variables in hungarian syntax (though this aspect doesn't seem to be followed in the the Source SDK)
<!--quoteo--><div class='quotetop'>QUOTE</div><div class='quotemain'><!--quotec-->@Scythe (to keep at least one wheel on the track, here)
....
If I'm wrong here and these are not strings<!--QuoteEnd--></div><!--QuoteEEnd-->
If I remember correctly, LUA is very promiscuous. There is no type to the variables, you can put whatever you want in them. It comes down to how Scythe handles it in the C++ side of things.
I have this friend back home that is really tall and lanky, so I call him a pole. He gets annoyed with me.
He is also polish.