Re: Why?? (prog question)
Polytropon wrote: Okay, now I understand what you mean. "Consistency" refers to the usage of spacing / tabbing for a given project that is adopted by several programmers. Yes, I agree with that: It's a very bad idea to have many different styles within the same project. . . . When I need to read / work with other's code, it's can develop into problems. Natural habits like hitting the tab key are very hard to change several times, for each project a different rule. . . . Not all editors have this ability. And especially under low level circumstances, e. g. editing with vi in SUM required in a maintenance phase, you'll be happy about every keystroke you can save. Most of my work is in a setting where the development machine is different from the target machine. Usually on a development machine you have the luxury of setting up all the tools you want and configuring them however you want. If you spend more time editing on the fly on a target machine, then that creates a different scenario, similar to doing sysadmin work. I've made most of my main points, and I think we've got to where differences of opinion now rest mainly on taste, which in turn is often guided by what you're used to. Consequently it's not possible to get much further, especially with the "I like 4 spaces because I'm used to them" vs. "I like 8-level tabs because I'm used to them" argument. I find that as I move from project to project, indentation standards do change. I find that where people have the resources to fully configure their development machines, reasonably thoughtful people who have experience in both standards end up converging on spaces being better than tabs because they are neater. I also find that, given such a configuration choice, more people find 4-space indentation looks better on the screen than go with 2 or 8 or 3. Consequently I stick with '4 spaces for indentation' as my norm, and if I have to switch to something else for a given project because people are using that standard, then I will change my editor settings. I'd like to add that tab based indentation is independent from the functionalities of a specific editor. It's even handy for printing where the tab width can be set to a certain value. Okay, your counterargument could now be: "Who prints today anyway?" :-) I'm more concerned with things like diff listings, where lines are preceded with: > which breaks the tab indentation because everything is pushed over by a space or two. Personally, I have the (maybe outdated) opinion that a programmer should not only care for his programs to be valid, correct, efficient, well structured, intended and documented, but also tidy and styled. What's to understand from these words can be very individual, I agree. We agree on this point, which is why we're having this discussion. There are lots of cases where it's hard to make code line up the way you want it with tabs. Often code that looks good with one tab length setting (say 8) doesn't look so good with another (say 4). It gets especially bad when there are a few space characters thrown in, which people often do. Okay, I didn't think of this. Taking this argument into mind, spaces can be useful for parameter lists that don't fit into one line, but should line up after the opening (, e. g. foofunction(&data, "%d,%d,%d", doodle.x, doodle.y, doodle,z, foo, bar, pups, furz, "This is some stupid text.", doom[dee].quoggle); This wouldn't be easy to achieve with tabs, especially when their width may vary. Even an 'if' or 'while' statement that spans more than one line can have problems like this. Nice discussion. -Will ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Why?? (prog question)
Oliver Fromme wrote Of course this is purely a matter of taste and personal preference. My preference is similar to yours, but my main reasoon is to save space. I think it is a ridiculous waste of space if every third line consisted only of a sole brace (opening or closing). To my eye, such lines that are almost empty break the natural structure of a piece of source code. I insert empty lines quite often in order to group source lines logically, but brace lines break that grouping visually. There is a very logical reason in C for wanting to put the opening brace of an 'if' statement on a separate line: preprocessor statements. Many editors, including vi / vim, and no doubt emacs, have a brace matching facility. If I put the cursor over a closing brace, say, and hit the % key, it puts me onto the matching opening brace. However in this scenario: int foo( int x ) { #ifdef SCENARIO_A if ( x<3 ) { #else if ( x<2 ) { #endif // . . . } // . . . } matching the closing brace of foo() will fail, as the number of braces no longer matches. Putting the opening brace of the 'if' on another line solves this problem. -Will ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Why?? (prog question)
On Tue, 31 Mar 2009 18:53:51 -0400, William Gordon Rutherdale wrote: > Are you serious? Serious question, yes. > You set the standard on a given project. You decide > whether you are using spaces or tabs. If spaces, you decide how many > spaces per indent level. You ask the programmers to submit code in that > format. It doesn't jump around randomly from one line to the next. Okay, now I understand what you mean. "Consistency" refers to the usage of spacing / tabbing for a given project that is adopted by several programmers. Yes, I agree with that: It's a very bad idea to have many different styles within the same project. > You are trying to make it sound like a big problem, but it isn't. When I need to read / work with other's code, it's can develop into problems. Natural habits like hitting the tab key are very hard to change several times, for each project a different rule. > Just my view based on years of experience. Don't take it too seriously. Okay, understood. "Better" often depends on what one is used to, except it can be put into a standpoint-independent discussion of pros and cons. > > When I would compare both indentation forms, I'd say that tabbing > > is the better form because > > + you can set your individually preferred tab with using the > >settings of your editor, be it 1, 4 or 8, > > > Why is this flexibility important? The more important thing is to have > consistently indented code. There is no great benefit in letting > different programmers see the code indented to different levels. They > just want to be able to read it. But the ability to read it is not the only important thing. It's how you use it, because programmers usually do more than just reading, they continue developing. The tab approach allows them to have their individual viewing options without needing to reformat the code. While programmer A likes ^TD2, another might want to work with ^TD8 or even ^TD10. The code stays the same. > > + you can change the indentation while you're coding, e. g. when > >the indentation level makes the code exceed the right margin > >of your editor's window, > So what? How many times have you actually done this in the past year? > Be honest. I belong to the ones who like ^TD8. The ability of changing the indentation width wasn't meant to be an agrument *for me*, but *for me and others*. It's not that I change the width very often, and as I think you've already guessed, I don't do it on a regular basis. But maybe if I pass ^TD8 code to you, you would want to work with it in ^TD4. THIS is the ability of changing I wanted to refer to. > > + you need more keypressing to get through the indentation with > >the spaces, one keypress per space, while you only need one > >keypress per tab (which equals one indentation level), > > > Not true. You set up your editor settings to automatically do this for > you. Most editors have this capability. Not all editors have this ability. And especially under low level circumstances, e. g. editing with vi in SUM required in a maintenance phase, you'll be happy about every keystroke you can save. > On my editor (vim) it only > takes at most one keypress to indent. You still might use the tab key, > or even have the editor automatically format for you based on syntax. > Editors have done this for decades. Your objection is specious. I'd like to add that tab based indentation is independent from the functionalities of a specific editor. It's even handy for printing where the tab width can be set to a certain value. Okay, your counterargument could now be: "Who prints today anyway?" :-) Not every programmer uses vim, emacs or Eclipse. Some really like the "old fashioned" ways like joe. The tabbing approach allows them not to take the indentation spaces as what they are: space characters. > > + per indentation level only 1 byte is needed (tab = ASCII 9), while > >spacing requires more bytes, one per space (space = ASCII 32), > > > Are you telling me that in an age when most cheap user workstations have > hundreds of gigabytes of disk space, you need this kind of savings? > This is a *very* weak point. Maybe, but it *is* a point. :-) > > + while you can convert tabs into spaces, you cannot easily convert > >spaces back into tabs, and finally > > > Not true. It is extremely easy to convert both directions. The unix > 'expand' command converts one direction, and 'unexpand' goes the reverse > direction. These unix utilities have been around as long as 'cat' and 'ls'. Thanks for this advice, these seem to be really handy tools. It's worth mentioning that they will work only as ling as the "internal guidelines" for spacing / tabbing are followed, or else only rubbish will come out. > Moreover the whole point is moot anyway. There are lots of high quality > code formatters available. One called 'Artistic Style' is well known > and very capable. On a lot of project
Re: Why?? (prog question)
Polytropon wrote: > FreeBSD defines additional exit codes to specify the reason for > exiting more precisely in /usr/include/sysexits.h - for your > example, exit(EX_USAGE); would be a good exit code. Actually, no. The purpose of the codes is for communication between SMTP processes (e.g. between an MTA such as sendmail and a delivery agent such as procmail), so the MTA can determine the meaning (severity) of the error and how to proceed. The only standard exit codes for "normal" programs are EXIT_SUCCESS and EXIT_FAILURE. You should use these. > [where to put braces] > In fact, I'm sticking to the concept that only the highest level > of "code groupers" deserve a new line {: these are functions in > C and class methods in C++. Everything else has the { appended > (after a space) to the construct that causes the {. So if you find > a }, you only need to look up. It's obvious that a } is caused > by a {, but you want to know the construct that made it appear, > for example if(), while(), a struct definition or something similar. > With this concept at hand, looking up will make you find this > construct in question at the first glance. Of course this is purely a matter of taste and personal preference. My preference is similar to yours, but my main reasoon is to save space. I think it is a ridiculous waste of space if every third line consisted only of a sole brace (opening or closing). To my eye, such lines that are almost empty break the natural structure of a piece of source code. I insert empty lines quite often in order to group source lines logically, but brace lines break that grouping visually. That's probably one of the reasons why I like Python so much: There are no braces for source structuring at all. This allows me to write very compact code _and_ structure it logically at the same time, making it easily readable and comprehensible. Furthermore, Python gets rid of all of the brace problems that C has, e.g. relating an "else" to the wrong "if" when multiple "if" statements are nested, and forgetting to add braces when you add a second line to an "if" branch (unless you always use braces in C, even when they're superfluous, but again that's a waste of space and does not really improve readability). I could go on for hours, but this is really off-topic now, so we should take this to the -chat list (or to private mail). Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "One of the main causes of the fall of the Roman Empire was that, lacking zero, they had no way to indicate successful termination of their C programs." -- Robert Firth ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Why?? (prog question)
Polytropon wrote: On Tue, 31 Mar 2009 07:48:00 -0400, William Gordon Rutherdale wrote: Tabbing is the worst form of indentation. It is *much* better to use spaces consistently. may I ask what exactly you mean by "consistently"? I've seen various opinions about how many spaces make up one indentation level, beginning from 1, over 4, up to 10. Where's the consistency, or is it defined on a per-programmer basis? Are you serious? You set the standard on a given project. You decide whether you are using spaces or tabs. If spaces, you decide how many spaces per indent level. You ask the programmers to submit code in that format. It doesn't jump around randomly from one line to the next. You are trying to make it sound like a big problem, but it isn't. And why is this much better? Just my view based on years of experience. Don't take it too seriously. When I would compare both indentation forms, I'd say that tabbing is the better form because + you can set your individually preferred tab with using the settings of your editor, be it 1, 4 or 8, Why is this flexibility important? The more important thing is to have consistently indented code. There is no great benefit in letting different programmers see the code indented to different levels. They just want to be able to read it. + you can change the indentation while you're coding, e. g. when the indentation level makes the code exceed the right margin of your editor's window, So what? How many times have you actually done this in the past year? Be honest. + you need more keypressing to get through the indentation with the spaces, one keypress per space, while you only need one keypress per tab (which equals one indentation level), Not true. You set up your editor settings to automatically do this for you. Most editors have this capability. On my editor (vim) it only takes at most one keypress to indent. You still might use the tab key, or even have the editor automatically format for you based on syntax. Editors have done this for decades. Your objection is specious. + per indentation level only 1 byte is needed (tab = ASCII 9), while spacing requires more bytes, one per space (space = ASCII 32), Are you telling me that in an age when most cheap user workstations have hundreds of gigabytes of disk space, you need this kind of savings? This is a *very* weak point. + while you can convert tabs into spaces, you cannot easily convert spaces back into tabs, and finally Not true. It is extremely easy to convert both directions. The unix 'expand' command converts one direction, and 'unexpand' goes the reverse direction. These unix utilities have been around as long as 'cat' and 'ls'. Moreover the whole point is moot anyway. There are lots of high quality code formatters available. One called 'Artistic Style' is well known and very capable. On a lot of projects these days, people get sick of these kinds of arguments and just run all the code they receive through a code formatter like astyle. It lets you set all kinds of options such as brace placement, spacing between parameters, indentation method, and so on. If asking people to change their editor settings doesn't work, this thing fixes it up. + even FreeBSD uses the tabbing style. And therefore if I submit code for FreeBSD then I will use that format. However I wouldn't recommend it for other projects where that decision has not been established. I'm aware that one can argue about where { is to be placed, but I don't see any valid reason to use spaces for indentation instead of tabs (which I would even call "standard"). It's a honest question: What are your arguments for using tabs? Hint: "it is *much* better" doesn't count. :-) There are lots of cases where it's hard to make code line up the way you want it with tabs. Often code that looks good with one tab length setting (say 8) doesn't look so good with another (say 4). It gets especially bad when there are a few space characters thrown in, which people often do. -Will ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Why?? (prog question)
On Tue, Mar 31, 2009 at 09:01:42PM +0200, Polytropon wrote: > On Tue, 31 Mar 2009 08:54:17 -0700, Gary Kline wrote: > > > 1. Use the tab character for indentation. You can set its > > >length with your favourite editor (e. g. mcedit: F9, > > >Options, General; joe: ^TD). Don't waste with spaces. > > > > Ja, been doing this since 1978. Does anybody hit space-key > > 8 times!? > > I've seen "corporate guideline" for indentation = 10 spaces. > Used ^TD8 and then finally replace tab -> ' '. :-) > (sounds like corp. mentality... ) > > > > > 2. The main() function should be declared as > > > int main(int argc, char *argv[]) > > >or > > > int main(int argc, char **argv) > > >Note that it's returning (int). Use this functionality. > > > > I've come to prefer the *char argv[] ... I didn't use the formal int > > return because this was supposed throwaway code. (Going on years now > > tho, so ... my-bad.) > > The standard assumption of the return code is (int), so if > it's not declared, it's (int) anyway. > sure; and the code i've been writing as "prefab'd" C is as clean and explicit as i can make it. difft with throwaway stuff. [ may need to rethink that!] > > > > > 4. Use the predefined return codes, don't hardcode them. > > >FreeBSD has EXiT_SUCCESS and EXIT_FAILURE, they're for > > >maximum compatibility (such as with Linux). There are > > >more exit codes for differentiation, but they're specific > > >to FreeBSD, as far as I know. > > > > This I did not know. I have a prefab include file with a bunch > > of my own similar #defines. Wow, great! > > FreeBSD defines additional exit codes to specify the reason for > exiting more precisely in /usr/include/sysexits.h - for your > example, exit(EX_USAGE); would be a good exit code. > > I don't know how far this is adopted in Linux, but I think you > can only use the C99 two standard return codes. > > >From "man 3 exit": > The C Standard (ISO/IEC 9899:1999 (``ISO C99'')) defines the values 0, > EXIT_SUCCESS, and EXIT_FAILURE as possible values of status. > > > > > > 5. This is highly debatable: Use a good style for { and }. > > > > > > > Well, you're using the K&R { }; but for me, the "Ingres" > > style [[ yes, it was invented by someone else ]] gets my vote. > > I scan > > { > > and > > } > > > > more easily. 6 of one, half-dozen of another... . > > In fact, I'm sticking to the concept that only the highest level > of "code groupers" deserve a new line {: these are functions in > C and class methods in C++. Everything else has the { appended > (after a space) to the construct that causes the {. So if you find > a }, you only need to look up. It's obvious that a } is caused > by a {, but you want to know the construct that made it appear, > for example if(), while(), a struct definition or something similar. > With this concept at hand, looking up will make you find this > construct in question at the first glance. > it really is what you're used to. somehow, several weeks ago, a function just would not behave, and after close to an hour of using vi's "showmatch", i discovered that i was missing one closing brace. *mumble* > You could see this in the example. > > But as we'll all agree, this is a thing of individual preference. > > > > > Here is the program again, with some stylistic modifications > > > and the "correct" (read: recommended, usual) exit code handling: > > > > I'll swipe this. I use this code with openoffice and abiword > > because I compose with vi; but I almost always forget to run > > my text thru joinlines and have to quit the word processor, run > > jlines bar; mv bar foo; then restart the word processor. > > I figure that I've spend several centuries of my lifetime messing > > with jlines, so i'm overdue for doing it right > > I think OpenOffice has the function Input - from file (at least > the german version has: Alt-E D = Einfügen Datei). This makes it > easier to incorporate text from an external file. > thanks for the datapoint; i'll check. i type virtually all text in vi just because my fingers know it. (i've been in openoffice and found myself hitting the escape key or "/" to search ... and other vi-isms. :) gary > > -- > Polytropon > >From Magdeburg, Germany > Happy FreeBSD user since 4.0 > Andra moi ennepe, Mousa, ... > ___ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org" -- Gary Kline kl...@thought.org http://www.thought.org Public Service Unix http://jottings.thought.org http://transfinite.thought.org The 2.41a release of Jottings: http:
Re: Why?? (prog question)
On Tue, Mar 31, 2009 at 07:50:22AM -0400, William Gordon Rutherdale wrote: > This isn't a BSD question. It's just about elementary C. As other > people pointed out, you could have easily caught it anyway just by > turning on warnings. > > -Will > yep, you're right. i did have gcc aliased to gcc -Wall; but somehow it got lost. It's back. gary -- Gary Kline kl...@thought.org http://www.thought.org Public Service Unix http://jottings.thought.org http://transfinite.thought.org The 2.41a release of Jottings: http://jottings.thought.org/index.php ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Why?? (prog question)
On Tue, 31 Mar 2009 13:59:16 +0200, Polytropon wrote: > When I would compare both indentation forms, I'd say that tabbing > is the better form because > + you can set your individually preferred tab with using the >settings of your editor, be it 1, 4 or 8, I like using TAB for indentation too, but when I see people setting TAB to a different size than 8 it makes me want to swear. There is a TAB size and an 'indentation level' size. These should be kept separate, and any modern editor will do it just fine! It is a bit amusing that nobody has answered the original question so far though }:-) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Why?? (prog question)
On Tue, 31 Mar 2009 19:20:17 +0100, Bruce Cran wrote: > Linux seems to have adopted sysexits.h too, which provides error codes > such as EX_USAGE and EX_CANTCREAT. Good to know this, thanks. I'm not a big Linux user and a much smaller Linux programmer (read: I don't program for Linux), so I wasn't aware that they use it, too. > However, in FreeBSD at least the most > common programming style is to use 1 for error and 0 for success - e.g. > from style(9): > > errx(1, "number overflowed"); This matches the definition of the two EXIT_* variables in the standard library header file: % grep EXIT /usr/include/stdlib.h #define EXIT_FAILURE1 #define EXIT_SUCCESS0 It's no problem to use 0 and 1, but personally, I think the "verbose reason" is better to read. :-) And thanks for the pointer to "man 9 style", I see that I've practiced a quite good style over the years without even knowing it. :-) -- Polytropon >From Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Why?? (prog question)
On Tue, 31 Mar 2009 08:54:17 -0700, Gary Kline wrote: > > 1. Use the tab character for indentation. You can set its > >length with your favourite editor (e. g. mcedit: F9, > >Options, General; joe: ^TD). Don't waste with spaces. > > Ja, been doing this since 1978. Does anybody hit space-key > 8 times!? I've seen "corporate guideline" for indentation = 10 spaces. Used ^TD8 and then finally replace tab -> ' '. :-) > > 2. The main() function should be declared as > > int main(int argc, char *argv[]) > >or > > int main(int argc, char **argv) > >Note that it's returning (int). Use this functionality. > > I've come to prefer the *char argv[] ... I didn't use the formal int > return because this was supposed throwaway code. (Going on years now > tho, so ... my-bad.) The standard assumption of the return code is (int), so if it's not declared, it's (int) anyway. > > 4. Use the predefined return codes, don't hardcode them. > >FreeBSD has EXiT_SUCCESS and EXIT_FAILURE, they're for > >maximum compatibility (such as with Linux). There are > >more exit codes for differentiation, but they're specific > >to FreeBSD, as far as I know. > > This I did not know. I have a prefab include file with a bunch > of my own similar #defines. Wow, great! FreeBSD defines additional exit codes to specify the reason for exiting more precisely in /usr/include/sysexits.h - for your example, exit(EX_USAGE); would be a good exit code. I don't know how far this is adopted in Linux, but I think you can only use the C99 two standard return codes. >From "man 3 exit": The C Standard (ISO/IEC 9899:1999 (``ISO C99'')) defines the values 0, EXIT_SUCCESS, and EXIT_FAILURE as possible values of status. > > 5. This is highly debatable: Use a good style for { and }. > > > > Well, you're using the K&R { }; but for me, the "Ingres" > style [[ yes, it was invented by someone else ]] gets my vote. > I scan > { > and > } > > more easily. 6 of one, half-dozen of another... . In fact, I'm sticking to the concept that only the highest level of "code groupers" deserve a new line {: these are functions in C and class methods in C++. Everything else has the { appended (after a space) to the construct that causes the {. So if you find a }, you only need to look up. It's obvious that a } is caused by a {, but you want to know the construct that made it appear, for example if(), while(), a struct definition or something similar. With this concept at hand, looking up will make you find this construct in question at the first glance. You could see this in the example. But as we'll all agree, this is a thing of individual preference. > > Here is the program again, with some stylistic modifications > > and the "correct" (read: recommended, usual) exit code handling: > > I'll swipe this. I use this code with openoffice and abiword > because I compose with vi; but I almost always forget to run > my text thru joinlines and have to quit the word processor, run > jlines bar; mv bar foo; then restart the word processor. > I figure that I've spend several centuries of my lifetime messing > with jlines, so i'm overdue for doing it right I think OpenOffice has the function Input - from file (at least the german version has: Alt-E D = Einfügen Datei). This makes it easier to incorporate text from an external file. -- Polytropon >From Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Why?? (prog question)
On Tue, 31 Mar 2009 11:21:22 +0200 Polytropon wrote: > 4. Use the predefined return codes, don't hardcode them. >FreeBSD has EXiT_SUCCESS and EXIT_FAILURE, they're for >maximum compatibility (such as with Linux). There are >more exit codes for differentiation, but they're specific >to FreeBSD, as far as I know. Linux seems to have adopted sysexits.h too, which provides error codes such as EX_USAGE and EX_CANTCREAT. However, in FreeBSD at least the most common programming style is to use 1 for error and 0 for success - e.g. from style(9): errx(1, "number overflowed"); -- Bruce Cran ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Why?? (prog question)
Wojciech Puchar wrote: Tabbing is the worst form of indentation. It is *much* better to use spaces consistently. stupid discussion and off topic. everybody write code as he/she like, or as a team decided if it's not single person work. only end result matters. you know real programmers code everything on one line. sub f...@s[$x,$...@s[($y+=$s[$x])%...@s,$x];$s[$x++]+$s[$...@s}@k=pop=~/../g;f$y+=hex$k[...@k]for@s=0..255;$x=1;$y=0;$/=\1;print$_^chr$s[f$...@s]for<> ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org" ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Why?? (prog question)
Josh Carroll wrote: > [...] > Note also that your main should have an int return type and should > return a value. His main() function _did_ have an int return type (it wasn't declared to be void), but of course it's better style to write int explicitly. By the way, FreeBSD's style(9) recommends to write the function return type on a separate line and begin the function name on column 1, like this: int main (int argc, char *argv[]) { ... } The clear advantage is that you can easily grep for the definition of a particular function in a bunch of source files: grep '^main' *.c Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Perl is worse than Python because people wanted it worse. -- Larry Wall ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Why?? (prog question)
On Tue, Mar 31, 2009 at 11:21:22AM +0200, Polytropon wrote: > I don't want to start a "style debate", but forgive me the > following annotations: > > 1. Use the tab character for indentation. You can set its >length with your favourite editor (e. g. mcedit: F9, >Options, General; joe: ^TD). Don't waste with spaces. Ja, been doing this since 1978. Does anybody hit space-key 8 times!? > > 2. The main() function should be declared as > int main(int argc, char *argv[]) >or > int main(int argc, char **argv) >Note that it's returning (int). Use this functionality. I've come to prefer the *char argv[] ... I didn't use the formal int return because this was supposed throwaway code. (Going on years now tho, so ... my-bad.) > > 3. In case of errors (e. g. incorrect number of parameters) >use fprintf() to stderr, or perror() with the builtin >error handling (e. g. for "file not found" by fopen()). > > 4. Use the predefined return codes, don't hardcode them. >FreeBSD has EXiT_SUCCESS and EXIT_FAILURE, they're for >maximum compatibility (such as with Linux). There are >more exit codes for differentiation, but they're specific >to FreeBSD, as far as I know. This I did not know. I have a prefab include file with a bunch of my own similar #defines. Wow, great! > > 5. This is highly debatable: Use a good style for { and }. > Well, you're using the K&R { }; but for me, the "Ingres" style [[ yes, it was invented by someone else ]] gets my vote. I scan { and } more easily. 6 of one, half-dozen of another... . > 6. Use delimiters around operators, e. g. buf[strlen(buf) - 1] >instead of buf[strlen(buf)-1]; increases readability. > Yup. > Here is the program again, with some stylistic modifications > and the "correct" (read: recommended, usual) exit code handling: > > I'll swipe this. I use this code with openoffice and abiword because I compose with vi; but I almost always forget to run my text thru joinlines and have to quit the word processor, run jlines bar; mv bar foo; then restart the word processor. I figure that I've spend several centuries of my lifetime messing with jlines, so i'm overdue for doing it right gary > > > /* > * simple prog to join all | very nearly all lines of a text file > * that make up one paragraph into one LONG line. > * > * paragraphs are delimiated by a single \n break. > */ > > #include > #include > #include > > int main(int argc, char *argv[]) > { > char buf[65536]; > > > if(argc == 1) { > fprintf(stderr, "Usage: %s < file > newfile\n", argv[0]); > exit(EXIT_FAILURE); > } > > while (fgets(buf, sizeof buf, stdin)) { > if(*buf == '\n') { > fprintf(stdout, "\n\n"); > } else { > buf[strlen(buf) - 1] = ' '; > fputs(buf, stdout); > } > } > > return EXIT_SUCCESS; > } > > > > > > Note that compiling with -Wall (always a good option) doesn't > show any warning. > > > > I read my advices again... makes me sound so old! :-) > > > > -- > Polytropon > From Magdeburg, Germany > Happy FreeBSD user since 4.0 > Andra moi ennepe, Mousa, ... -- Gary Kline kl...@thought.org http://www.thought.org Public Service Unix http://jottings.thought.org http://transfinite.thought.org The 2.41a release of Jottings: http://jottings.thought.org/index.php ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Why?? (prog question)
Tabbing is the worst form of indentation. It is *much* better to use spaces consistently. stupid discussion and off topic. everybody write code as he/she like, or as a team decided if it's not single person work. only end result matters. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Why?? (prog question)
On Tue, 31 Mar 2009 07:48:00 -0400, William Gordon Rutherdale wrote: > Tabbing is the worst form of indentation. It is *much* better to use > spaces consistently. may I ask what exactly you mean by "consistently"? I've seen various opinions about how many spaces make up one indentation level, beginning from 1, over 4, up to 10. Where's the consistency, or is it defined on a per-programmer basis? And why is this much better? When I would compare both indentation forms, I'd say that tabbing is the better form because + you can set your individually preferred tab with using the settings of your editor, be it 1, 4 or 8, + you can change the indentation while you're coding, e. g. when the indentation level makes the code exceed the right margin of your editor's window, + you need more keypressing to get through the indentation with the spaces, one keypress per space, while you only need one keypress per tab (which equals one indentation level), + per indentation level only 1 byte is needed (tab = ASCII 9), while spacing requires more bytes, one per space (space = ASCII 32), + while you can convert tabs into spaces, you cannot easily convert spaces back into tabs, and finally + even FreeBSD uses the tabbing style. I'm aware that one can argue about where { is to be placed, but I don't see any valid reason to use spaces for indentation instead of tabs (which I would even call "standard"). It's a honest question: What are your arguments for using tabs? Hint: "it is *much* better" doesn't count. :-) // EDIT: added one further argument pro tab /* -- Polytropon >From Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Why?? (prog question)
Polytropon wrote: I don't want to start a "style debate", but forgive me the following annotations: 1. Use the tab character for indentation. You can set its length with your favourite editor (e. g. mcedit: F9, Options, General; joe: ^TD). Don't waste with spaces. 2. The main() function should be declared as int main(int argc, char *argv[]) or int main(int argc, char **argv) Note that it's returning (int). Use this functionality. 3. In case of errors (e. g. incorrect number of parameters) use fprintf() to stderr, or perror() with the builtin error handling (e. g. for "file not found" by fopen()). 4. Use the predefined return codes, don't hardcode them. FreeBSD has EXiT_SUCCESS and EXIT_FAILURE, they're for maximum compatibility (such as with Linux). There are more exit codes for differentiation, but they're specific to FreeBSD, as far as I know. 5. This is highly debatable: Use a good style for { and }. 6. Use delimiters around operators, e. g. buf[strlen(buf) - 1] instead of buf[strlen(buf)-1]; increases readability. Here is the program again, with some stylistic modifications and the "correct" (read: recommended, usual) exit code handling: /* * simple prog to join all | very nearly all lines of a text file * that make up one paragraph into one LONG line. * * paragraphs are delimiated by a single \n break. */ #include #include #include int main(int argc, char *argv[]) { char buf[65536]; if(argc == 1) { fprintf(stderr, "Usage: %s < file > newfile\n", argv[0]); exit(EXIT_FAILURE); } while (fgets(buf, sizeof buf, stdin)) { if(*buf == '\n') { fprintf(stdout, "\n\n"); } else { buf[strlen(buf) - 1] = ' '; fputs(buf, stdout); } } return EXIT_SUCCESS; } Note that compiling with -Wall (always a good option) doesn't show any warning. I read my advices again... makes me sound so old! :-) Tabbing is the worst form of indentation. It is *much* better to use spaces consistently. -Will ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Why?? (prog question)
This isn't a BSD question. It's just about elementary C. As other people pointed out, you could have easily caught it anyway just by turning on warnings. -Will Gary Kline wrote: people, i've been under the weather for days and will probably be for a few more. new and TEMPORARY meds dont like me, ugh. can anybody clue me in why the followin joinline program fails to catch if argc == 1? /* * simple prog to join all | very nearly all lines of a text file that * make up one paragraph into one LONG line. * * paragraphs are delimiated by a single \n break. */ #include #include #include main(int argc, char argv[]) { char buf[65536]; if (argc == 1) { printf("Usage: %s < file > newfile\n", argv[0]); exit (-1); } while (fgets(buf, sizeof buf, stdin) ) { if (*buf == '\n') { fprintf(stdout, "\n\n"); } else { buf[strlen(buf)-1] = ' '; fputs(buf, stdout); } } } ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Why?? (prog question)
On Tue, 31 Mar 2009 07:48:00 -0400, William Gordon Rutherdale wrote: > Tabbing is the worst form of indentation. It is *much* better to use > spaces consistently. may I ask what exactly you mean by "consistently"? I've seen various opinions about how many spaces make up one indentation level, beginning from 1, over 4, up to 10. Where's the consistency, or is it defined on a per-programmer basis? And why is this much better? When I would compare both indentation forms, I'd say that tabbing is the better form because + you can set your individually preferred tab with using the settings of your editor, be it 1, 4 or 8, + you can change the indentation while you're coding, e. g. when the indentation level makes the code exceed the right margin of your editor's window, + per indentation level only 1 byte is needed (tab = ASCII 9), while spacing requires more bytes, one per space (space = ASCII 32), + while you can convert tabs into spaces, you cannot easily convert spaces back into tabs, and finally + even FreeBSD uses the tabbing style. I'm aware that one can argue about where { is to be placed, but I don't see any valid reason to use spaces for indentation instead of tabs (which I would even call "standard"). It's a honest question: What are your arguments for using tabs? Hint: "it is *much* better" doesn't count. :-) -- Polytropon >From Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Why?? (prog question)
I don't want to start a "style debate", but forgive me the following annotations: 1. Use the tab character for indentation. You can set its length with your favourite editor (e. g. mcedit: F9, Options, General; joe: ^TD). Don't waste with spaces. 2. The main() function should be declared as int main(int argc, char *argv[]) or int main(int argc, char **argv) Note that it's returning (int). Use this functionality. 3. In case of errors (e. g. incorrect number of parameters) use fprintf() to stderr, or perror() with the builtin error handling (e. g. for "file not found" by fopen()). 4. Use the predefined return codes, don't hardcode them. FreeBSD has EXiT_SUCCESS and EXIT_FAILURE, they're for maximum compatibility (such as with Linux). There are more exit codes for differentiation, but they're specific to FreeBSD, as far as I know. 5. This is highly debatable: Use a good style for { and }. 6. Use delimiters around operators, e. g. buf[strlen(buf) - 1] instead of buf[strlen(buf)-1]; increases readability. Here is the program again, with some stylistic modifications and the "correct" (read: recommended, usual) exit code handling: /* * simple prog to join all | very nearly all lines of a text file * that make up one paragraph into one LONG line. * * paragraphs are delimiated by a single \n break. */ #include #include #include int main(int argc, char *argv[]) { char buf[65536]; if(argc == 1) { fprintf(stderr, "Usage: %s < file > newfile\n", argv[0]); exit(EXIT_FAILURE); } while (fgets(buf, sizeof buf, stdin)) { if(*buf == '\n') { fprintf(stdout, "\n\n"); } else { buf[strlen(buf) - 1] = ' '; fputs(buf, stdout); } } return EXIT_SUCCESS; } Note that compiling with -Wall (always a good option) doesn't show any warning. I read my advices again... makes me sound so old! :-) -- Polytropon >From Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Why?? (prog question)
On Mon, Mar 30, 2009 at 11:08:57PM -0400, Josh Carroll wrote: > On Mon, Mar 30, 2009 at 10:57 PM, Gary Kline wrote: > > people, i've been under the weather for days and will probably be for a few > > more. > > new and TEMPORARY meds dont like me, ugh. > > > > can anybody clue me in why the followin joinline program fails to catch if > > argc == 1? > > > > > > /* > > * simple prog to join all | very nearly all lines of a text file that > > * make up one paragraph into one LONG line. > > * > > * paragraphs are delimiated by a single \n break. > > */ > > > > #include > > #include > > #include > > > > main(int argc, char argv[]) > > { > > char buf[65536]; > > > > if (argc == 1) > > { > > printf("Usage: %s < file > newfile\n", argv[0]); > > exit (-1); > > } > > while (fgets(buf, sizeof buf, stdin) ) > > { > > if (*buf == '\n') > > { > > fprintf(stdout, "\n\n"); > > } > > else > > { > > buf[strlen(buf)-1] = ' '; > > fputs(buf, stdout); > > } > > } > > } > > main should be: > > int main(int argc, char **argv) > > or perhaps > > int main(int argc, char *argv[]) > > As is, you're defining int as char argv[] (e.g. char *) instead of char **. > > What will likely happen is you'll get a segmentation fault when you > try to run the program, since your printf format spec has %s, but > you're passing it a char. > > In fact, if you compile it with -Wall, you'll see the two problems > I've mentioned: > > t.c:13: warning: second argument of 'main' should be 'char **' > t.c: In function 'main': > t.c:20: warning: format '%s' expects type 'char *', but argument 2 has > type 'int' > > Change char argv[] to char *argv[] or char **argv and it should work properly. > > Note also that your main should have an int return type and should > return a value. > > Regards, > Josh you got it; as far as i know this is the first time that i've ever done the "char argv[]" instead of the "char *argv[]". thanks! gary :x > ___ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org" -- Gary Kline kl...@thought.org http://www.thought.org Public Service Unix http://jottings.thought.org http://transfinite.thought.org The 2.41a release of Jottings: http://jottings.thought.org/index.php ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Why?? (prog question)
Just 5 minutes too late. :) On Mon, Mar 30, 2009 at 9:13 PM, Joshua Gimer wrote: > main(int argc, char *argv[]) > > On Mon, Mar 30, 2009 at 8:57 PM, Gary Kline wrote: >> people, i've been under the weather for days and will probably be for a few >> more. >> new and TEMPORARY meds dont like me, ugh. >> >> can anybody clue me in why the followin joinline program fails to catch if >> argc == 1? >> >> >> /* >> * simple prog to join all | very nearly all lines of a text file that >> * make up one paragraph into one LONG line. >> * >> * paragraphs are delimiated by a single \n break. >> */ >> >> #include >> #include >> #include >> >> main(int argc, char argv[]) >> { >> char buf[65536]; >> >> if (argc == 1) >> { >> printf("Usage: %s < file > newfile\n", argv[0]); >> exit (-1); >> } >> while (fgets(buf, sizeof buf, stdin) ) >> { >> if (*buf == '\n') >> { >> fprintf(stdout, "\n\n"); >> } >> else >> { >> buf[strlen(buf)-1] = ' '; >> fputs(buf, stdout); >> } >> } >> } >> >> >> -- >> Gary Kline kl...@thought.org http://www.thought.org Public Service Unix >> http://jottings.thought.org http://transfinite.thought.org >> The 2.41a release of Jottings: http://jottings.thought.org/index.php >> >> ___ >> freebsd-questions@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-questions >> To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org" >> > > > > -- > Thx > Joshua Gimer > -- Thx Joshua Gimer ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Why?? (prog question)
main(int argc, char *argv[]) On Mon, Mar 30, 2009 at 8:57 PM, Gary Kline wrote: > people, i've been under the weather for days and will probably be for a few > more. > new and TEMPORARY meds dont like me, ugh. > > can anybody clue me in why the followin joinline program fails to catch if > argc == 1? > > > /* > * simple prog to join all | very nearly all lines of a text file that > * make up one paragraph into one LONG line. > * > * paragraphs are delimiated by a single \n break. > */ > > #include > #include > #include > > main(int argc, char argv[]) > { > char buf[65536]; > > if (argc == 1) > { > printf("Usage: %s < file > newfile\n", argv[0]); > exit (-1); > } > while (fgets(buf, sizeof buf, stdin) ) > { > if (*buf == '\n') > { > fprintf(stdout, "\n\n"); > } > else > { > buf[strlen(buf)-1] = ' '; > fputs(buf, stdout); > } > } > } > > > -- > Gary Kline kl...@thought.org http://www.thought.org Public Service Unix > http://jottings.thought.org http://transfinite.thought.org > The 2.41a release of Jottings: http://jottings.thought.org/index.php > > ___ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org" > -- Thx Joshua Gimer ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Why?? (prog question)
On Mon, Mar 30, 2009 at 10:57 PM, Gary Kline wrote: > people, i've been under the weather for days and will probably be for a few > more. > new and TEMPORARY meds dont like me, ugh. > > can anybody clue me in why the followin joinline program fails to catch if > argc == 1? > > > /* > * simple prog to join all | very nearly all lines of a text file that > * make up one paragraph into one LONG line. > * > * paragraphs are delimiated by a single \n break. > */ > > #include > #include > #include > > main(int argc, char argv[]) > { > char buf[65536]; > > if (argc == 1) > { > printf("Usage: %s < file > newfile\n", argv[0]); > exit (-1); > } > while (fgets(buf, sizeof buf, stdin) ) > { > if (*buf == '\n') > { > fprintf(stdout, "\n\n"); > } > else > { > buf[strlen(buf)-1] = ' '; > fputs(buf, stdout); > } > } > } main should be: int main(int argc, char **argv) or perhaps int main(int argc, char *argv[]) As is, you're defining int as char argv[] (e.g. char *) instead of char **. What will likely happen is you'll get a segmentation fault when you try to run the program, since your printf format spec has %s, but you're passing it a char. In fact, if you compile it with -Wall, you'll see the two problems I've mentioned: t.c:13: warning: second argument of 'main' should be 'char **' t.c: In function 'main': t.c:20: warning: format '%s' expects type 'char *', but argument 2 has type 'int' Change char argv[] to char *argv[] or char **argv and it should work properly. Note also that your main should have an int return type and should return a value. Regards, Josh ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Why?? (prog question)
people, i've been under the weather for days and will probably be for a few more. new and TEMPORARY meds dont like me, ugh. can anybody clue me in why the followin joinline program fails to catch if argc == 1? /* * simple prog to join all | very nearly all lines of a text file that * make up one paragraph into one LONG line. * * paragraphs are delimiated by a single \n break. */ #include #include #include main(int argc, char argv[]) { char buf[65536]; if (argc == 1) { printf("Usage: %s < file > newfile\n", argv[0]); exit (-1); } while (fgets(buf, sizeof buf, stdin) ) { if (*buf == '\n') { fprintf(stdout, "\n\n"); } else { buf[strlen(buf)-1] = ' '; fputs(buf, stdout); } } } -- Gary Kline kl...@thought.org http://www.thought.org Public Service Unix http://jottings.thought.org http://transfinite.thought.org The 2.41a release of Jottings: http://jottings.thought.org/index.php ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"