Re: Why?? (prog question)
Polytropon free...@edvax.de 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 sysexits.h 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)
On Tue, 31 Mar 2009 18:53:51 -0400, William Gordon Rutherdale will.rutherd...@utoronto.ca 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 projects these days, people get sick of these kinds
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 ( x3 ) {
#else
if ( x2 ) {
#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)
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)
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 stdio.h
#include string.h
#include stdlib.h
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 Tue, 31 Mar 2009 07:48:00 -0400, William Gordon Rutherdale
will.rutherd...@utoronto.ca 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)
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 stdio.h
#include string.h
#include stdlib.h
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)
On Tue, 31 Mar 2009 07:48:00 -0400, William Gordon Rutherdale
will.rutherd...@utoronto.ca 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)
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 stdio.h
#include string.h
#include stdlib.h
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)
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, 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 KR { }; 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 foo 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 stdio.h
#include string.h
#include stdlib.h
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)
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)
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)
On Tue, 31 Mar 2009 11:21:22 +0200 Polytropon free...@edvax.de 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)
On Tue, 31 Mar 2009 19:20:17 +0100, Bruce Cran br...@cran.org.uk 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 kl...@thought.org 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 KR { }; 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 foo 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 13:59:16 +0200, Polytropon free...@edvax.de 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, 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, Mar 31, 2009 at 09:01:42PM +0200, Polytropon wrote:
On Tue, 31 Mar 2009 08:54:17 -0700, Gary Kline kl...@thought.org 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 KR { }; 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 foo 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://jottings.thought.org/index.php
___
freebsd-questions@freebsd.org mailing list
Re: Why?? (prog question)
Polytropon wrote:
On Tue, 31 Mar 2009 07:48:00 -0400, William Gordon Rutherdale
will.rutherd...@utoronto.ca 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
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 stdio.h
#include string.h
#include stdlib.h
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
Re: Why?? (prog question)
On Mon, Mar 30, 2009 at 10:57 PM, Gary Kline kl...@thought.org 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 stdio.h
#include string.h
#include stdlib.h
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
Re: Why?? (prog question)
main(int argc, char *argv[])
On Mon, Mar 30, 2009 at 8:57 PM, Gary Kline kl...@thought.org 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 stdio.h
#include string.h
#include stdlib.h
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)
Just 5 minutes too late. :)
On Mon, Mar 30, 2009 at 9:13 PM, Joshua Gimer jgi...@gmail.com wrote:
main(int argc, char *argv[])
On Mon, Mar 30, 2009 at 8:57 PM, Gary Kline kl...@thought.org 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 stdio.h
#include string.h
#include stdlib.h
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)
On Mon, Mar 30, 2009 at 11:08:57PM -0400, Josh Carroll wrote:
On Mon, Mar 30, 2009 at 10:57 PM, Gary Kline kl...@thought.org 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 stdio.h
#include string.h
#include stdlib.h
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
