What advantage, if any, is provided by formatting C code as follows:
while(lock_file(lockdir)==0)
{
count++;
if(count==20)
{
fprintf(stderr,"Can't lock dir %s\n",lockdir);
exit(1);
}
sleep(3);
}
if(rmdir(serverdir)!=0)
{
switch(errno)
{
case EEXIST:
fprintf(stderr,"Server dir %s not empty\n",serverdir);
break;
default:
fprintf(stderr,"Can't delete dir %s\n",serverdir);
}
exit(1);
}
unlock_file(lockdir);
versus something more typical such as
while(lock_file(lockdir)==0) {
count++;
if(count==20) {
fprintf(stderr,"Can't lock dir %s\n",lockdir);
exit(1);
}
sleep(3);
}
if(rmdir(serverdir)!=0) {
switch(errno) {
case EEXIST:
fprintf(stderr,"Server dir %s not empty\n",serverdir);
break;
default:
fprintf(stderr,"Can't delete dir %s\n",serverdir);
}
exit(1);
}
unlock_file(lockdir);
I just find the top version difficult to read and to get the indenting level correct for statements outside of a long block, especially for longs blocks containing several nested blocks.
Only advantage I can see is just to be different and leave your fingerprints on code that you've written.
I notice vim formatting would have to be hand-rolled to handle the top case.
The top example is know as "Whitesmiths style". Wikipedia's entry on Indent Styles explains several styles along with their advantages and disadvantages.
The indentation you're seeing is Whitesmiths style. It's described in the first edition of Code Complete as "begin-end Block Boundaries". The basic argument for this style is that in languages like C (and Pascal) an if governs either a single statement or a block. Thus the whole block, not just its contents should be shown subordinate to the if-statement by being indented consistently.
XXXXXXXXXXXXXXX if (test)
XXXXXXXXXXXX one_thing();
XXXXXXXXXXXXXXX if (test)
X {
XXXXX one_thing();
XXXXX another_thing();
X }
Back when I first read this book (in the 90s) I found the argument for "begin-end Block Boundaries" to be convincing, though I didn't like it much when I put it into practice (in Pascal). I like it even less in C and find it confusing to read. I end up using what Steve McConnel calls "Emulating Pure Blocks" (Sun's Java Style, which is almost K&R).
XXXXXXXXXXXXXX X if (test) {
XXXXXX one_thing();
XXXXXX another_thing();
X }
This is the most common style used to program in Java (which is what I do all day). It's also most similar to my previous language which was a "pure block" language, requiring no "emulation". There are no single-statement bodies, blocks are inherent in the control structure syntax.
IF test THEN
oneThing;
anotherThing
END
Nothing. Indentation and other coding standards are a matter of preference.
Personal Preference I would have thought? I guess it has the code block in one vertical line so possibly easier to work out at a glance? Personally I prefer the brace to start directly under the previous line
It looks pretty standard to me. The only personal change I'd make is aligning the curly-braces with the start of the previous line, rather than the start of the next line, but that's just a personal choice.
Anyway, the style of formatting you're looking at there is a standard one for C and C++, and is used because it makes the code easier to read, and in particular by looking at the level of indentation you can tell where you are with nested loops, conditionals, etc. E.g.:
if (x == 0)
{
if (y == 2)
{
if (z == 3)
{
do_something (x);
}
}
}
OK in that example it's pretty easy to see what's happening, but if you put a lot of code inside those if statements, it can sometimes be hard to tell where you are without consistent indentation.
In your example, have a look at the position of the exit(1) statement -- if it weren't indented like that, it would be hard to tell where this was. As it is, you can tell it's at the end of that big if statement.
Code formatting is personal taste. As long as it is easy to read, it would pay for maintenance!
By following some formatting and commenting standards, first of all you show your respect to other people that will read and edit code written by you. If you don't accept rules and write somehow esoteric code the most probable result is that you will not be able communicate with other people (programmers) effectively. Code format is personal choice if software is written only by you and for you and nobody is expected to read it, but how many modern software is written only by one person ?
The "advantage" of Whitesmiths style (as the top one in your example is called) is that it mirrors the actual logical structure of the code:
indent if there is a logical dependency
place corresponding brackets on the same column so they are easy to find
opening and closing of a context (which may open/close a stack frame etc) are visible, not hidden
So, less if/else errors, loops gone wrong, and catches at the wrong level, and overall logical consistency.
But as benefactual wrote: within certain rational limits, formatting is a matter of personal preference.
Its just another style--people code how they like to code, and that is one accepted style (though not my preferred). I don't think it has much of a disadvantage or advantage over the more common style in which brackets are not indented but the code within them is. Perhaps one could justify it by saying that it more clearly delimits code blocks.
In order for this format to have "advantage", we really need some equivalent C code in another format to compare to!
Where I work, this indentation scheme is used in order to facilitate a home-grown folding editor mechanism.
Thus, I see nothing fundamentally wrong with this format - within certain rational limits, formatting is a matter of personal preference.
Related
Recently I learned some text editor has functions to check whether all parentheses are balanced inside a file. (e.g. check-parens in Emacs). It may even be able to highlight the 1st unbalanced parenthesis if there is any. However I am not clear whether there is a way to properly locate it instead of always highlight the 1st unbalanced occurrence.
Consider below code:
void foo()
{
int some_num0 = 0;
{
int some_num1 = 1;
{
int some_num2 = 2;
{
int some_num3 = 3;
//ops I forgot to close this block.
}
}
}
A simple balance check, (e.g. check-parens in Emacs) will bring me to the opening brace of foo's definition. However a more reasonable indication should bring me to somewhere around the innermost level, the one near some_num3. Is there a way to achieve this?
The parenthesis check basically reads the code and updates a counter whenever it hits a parenthesis. If it is an opening bracket, it adds 1 ; if it is a closing one, it adds -1 (subtracts 1). If the counter ever hits a negative number, there is a problem, and it tells you. If, at the end of the code, the counter is not zero, there also is a problem ; that is your case.
But how do you want it to know where the missing brace(s) actually is/are ? The only way to do something close to what you want is to check for the indentation as well. But what if your code is not properly indented ?
I do not know of any tool that checks for indentation while checking braces, and I doubt there is a good one (if any).
The fact is, the more you forget a parenthesis, and above all, the more you write code, the more you remember to not forget these parenthesis. Or at least, it is likely to happen.
So, do not blame your IDE for not being endowed with reason, but rather blame you for not immediately locating missing brackets. And write code.
Some of the popular Emacs libraries include, but are not limited to:
highlight-parentheses: https://github.com/nschum/highlight-parentheses.el
rainbow-delimiters: https://github.com/jlr/rainbow-delimiters
Here is a link to a recent modification that I made to one of the functions used by highlight-parentheses, which will preserve the overlays when using scroll-up, scroll-down, or mwheel-scroll: https://stackoverflow.com/a/25269210/2112489
Here is a link to a modified version of highlight-parentheses, which is what I use: https://stackoverflow.com/a/23998965/2112489 I have not yet updated the posted version of parens-mode to include the modification for scrolling that is referred to in the previous link. My personal preference is to add / delete overlays, instead of storing them at the beginning of the buffer and moving them around.
Here is a screen-shot of a modified version of highlight-parentheses:
(source: lawlist.com)
If you indented all of the closing braces by one level, would you still say that it would be more reasonable to indicate the 4th opening brace?
If not, perhaps it should be checking for consistent indentation too.
Not realy a check-parens solution but when something like this happens to me I usually mark the whole block and go M-x indent-region to have emacs try to indent the selected region correctly.
In your simple case it would indent them all one level (MRABs answer) and you would just close the last brace.
In a more complicated case indentation will break somewhere (i.e the code won't look like you expect it to do) and that is usually where the parenthesis is missing.
I just used notepad++ with the BracketsCheck plugin https://community.notepad-plus-plus.org/topic/14090/best-way-to-find-unmatched-parentheses/2. After some hours searching and trying VSCode plugins, n++ did it for me :) I was checking a 2.5K lines XML file with about 270 formula expressions. Checking parenthesis formula by formula using the usual matching parenthesis highlighting feature wasn't looking much of an option.
My coding style is to always put an opening brace on a new line:
int aBoringCFunction()
{
...
Apple used to follow this style but changed to have the { on the same line as the function. When using blocks Apple code always has the { directly after the ^:
dispatch_async(dispatch_get_main_queue(), ^{
...
Is there any reason why using my style with blocks would be problematic? For example:
dispatch_async(dispatch_get_main_queue(), ^
{
...
I prefer my style but if it causes problems with blocks then I will have to reconsider it.
Clarification
This question is regarding the Blocks extension to the C language. It is not a general question about braces. The questions is whether the Blocks extension has any ramifications on code style.
Both styles are perfectly correct; it's a matter of style and preference. The only way it will be problematic is that you might be expected to adhere to Apple's convention depending on who your code is for. Hence you might have to go back and change the formatting slightly before your work is accepted.
I think the block samples are mimicking Apple's standard, that's all. You can put your braces wherever you like. Suggest a thought about switching since samples online are likely to follow Apple. And it works pretty well.
This is one of the style-related things that people have argued the most about, and at the same time one that matters the least.
Having the brace on the same line is the "K&R" style, the style that was used in C from the very beginning. Having it on a separate line is perhaps the most common nowadays.
But there is no evidence that one of the two styles are better than the other for clarity. If someone argues over one style over the other, ask then for scientific research on the matter. I have yet to see such.
The only thing that's important is that the code style is consistent throughout your programs. If working as a programmer in a team, the whole team should be using the same style.
The c complier doesn't care where you put your braces. Its style I personal hate K&R style but what really matters is the coding standards where you write your code. If its just for personal use do whatever makes the code more readable for you.
Traditionally programmers have tried to use as few lines as possible because you can only see 24 at a time on the terminals that were being used. Putting the { on its own line just wasted screen space.
Nowadays with large high resolution monitors I think this is less of an issue and I, like you, put the braces on their own line for neatness.
Different people have very different coding tastes. In general, larger projects come with coding style guidelines. KDE, for example, likes it like you do: the { on the next line. They also like spaces in if statements:
if ( this_var > 42 )
Which personally I don't see the need for. I had a co-worker once that liked to have 5 blank lines after every function. For him the visual separation was important. For me, however, I like to get as much on the screen at once as I can.
There is no wrong. There is only white-space.
My most favorite commit-log I ever wrote for a project after we agreed on a common style (that has now lasted for coming up on 10 years):
2002-04-20 00:07 hardaker
* everything:
White space, oh glorious white space.
How great our though?
The code is fine.
We agree on functionality easily.
What really troubles us?
Something we can't see.
Something between the code.
We bow down to your magnificence,
For you are everywhere,
Between everything.
Pretty nothingness you are.
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
Should a function have only one return statement?
Hello,
gcc 4.4.4 c89
Is it good programming practice to return from 1 point in a function.
I have written a function below. However, I am returning from 2 possible points.
Is this good style?
static int init_data(struct timeout_data_t *timeout_data)
{
if(timeout_data == NULL) {
fprintf(stderr, " [ %s ] [ %d ]\n",
__func__, __LINE__);
return FALSE;
}
/* Assign data */
timeout_data->seconds = 3;
timeout_data->func_ptr = timeout_cb;
return TRUE;
}
If it aids readability, then there is nothing wrong with it.
Personally, I write this kind of code all of the time.
This is an ongoing religious-style debate without an accepted answer. There are many people on both sides of the argument, who feel strongly about it.
I don't think there's anything wrong with it personally, but the best approach is to go with the style guidelines of your team, if they have some (and if not, just ask about it. If anyone recoils in horror, it would be kinder to stick to single-return-point).
I've had managers that lived and died by the 1 return policy for the sake of "readability", even though it's much more readable in some cases without it.
The bottom line is... if the man that signs your paycheck says you're only going to use 1 return, use 1 return. The best way to do this is
type myfunc(params) {
type result = defaultValue;
// actual function here, word for word
// replace "return $1" with "result = $1"
return result;
}
This is a valid way to do things in their book, and will smile at your 1 return policy adherence. Of course, you know using this adds ZERO readability because all you've done is replace "return" (which is syntax highlighted) with "result =" which is not. But you've made your boss happy, which when you break it all down is what development is about anyway, right? :-)
In straight C, I think that error checking/parameter verification at the top of the function with a return (or possibly even multiple return points in the parameter verification) results in reasonably clean code. After that point, though, my opinion is that it is a good idea to have one single return at the bottom of the function. That helps avoid problems with cleanup (e.g., freeing of memory) that might be allocated in the workings of the function.
There's nothing inherently wrong about having more than one exit point, especially when you're returning on errors. Returning immediately usually makes for clearer code than having the whole thing wrapped in an if/else statement and setting some result flag to be returned at the end. (When you see "return result;", you have to look through all of the earlier code to see how and when result gets set. More moving parts == less clarity.)
You've tagged your questions as "C" which makes a difference.
In C you might write code such as
open file
process data
close file
If you put a return in the middle of the process data section then you're likely to skip the essential cleanup so it might be considered bad practice to have multiple return points because it's very easy to mess up.
If it was C++ then its best practice to let destructors handle cleanup so it's not nearly such a potential problem so this advice is somewhat obsolete in c++
As Oded and Andrzej Doyle pointed out there is nothing wrong with it.
They is no such thing as a golden rule when it comes to this.
The first an most important thing you have to keep in mind when writing code is that some one else will have to read it and make sense out of it. Maybe you will have to go about it in a couple of months, and if you have made a mess you will regret it.
Personally I always:
if the code is new used the coding style everybody else is using in the project.
If editing others code used the coding style already implemented there.
Avoid above all code optimizations (the compiler is best at that).
keep it clean and lean.
If your function is small enough (10-15 lines), as it should be :), then it really doesn't matter if you use a single return point or multiple one. Both are equally readable.
Problems start cropping up with badly designed large functions. In such cases both the styles, returning from a single point, and returning from multiple points, further complicates the function, although even in such cases I prefer returning early and returning at multiple points.
It's often the case that you have to check for several conditions etc before you start with the real work, and then you are tempted to do an early return, as in your code. I think this is fine for short methods, but when it gets more complicated I'd suggest to break your code in a "setup and check" method and a "real work" method, both having only one exit. Of course as long as it's readeable, it's fine to have multiple returns (e.g. in a long switch statement).
Failing (and thus returning) early is a very very very good practice. All the code after the checks is free of a lot of potential errors.
Reverse engineering code and I'm kind of appalled at the style, but I wanted to make sure there's no good reason for doing these things....
Is it just me or is this a horrible coding style
if ( pwbuf ) sprintf(username,"%s",pwbuf->pw_name);
else sprintf(username,"%d",user_id);
And why wrap code not intended for compilation in an
#if 0
....
#endif
Instead of comments?
EDIT: So as some explained below, this is due to the possibility to flummox /* */ which I didn't realize.
But I still don't understand, why not just use your programming environment tools or favorite text editor's macro's to block comment it out using "//"
wouldn't this be MUCH more straightforward and easy to know to visually skip?
Am I just inexperienced in C and missing why these things might be a good idea -- or is there no excuse, and I'm justified in feeling irritated at how ugly this code is?
#if 0 is used pretty frequently when the removed block contains block-comments
I won't say it's a good practice, but I see it rather often.
The single line flow-control+statement is easy enough to understand, although I personally avoid it (and most of the coding guidelines I've worked under forbid it)
BTW, I'd probably edit the title to be somewhat useful "Why use #if 0 instead of block comments"
If you have the following
#if 0
silly();
if(foo)
bar();
/* baz is a flumuxiation */
baz = fib+3;
#endif
If you naively replace the #if 0/#endif with /* */, that will cause the comment to end right after flumuxiation, causing a syntax error when you hit the */ in the place of the #endif above..
EDIT: One final note, often the #if 0 syntax is just used while developing, particularly if you have to support multiple versions or dependencies or hardware platforms. It's not unusual for the code to be modified to
#ifdef _COMPILED_WITHOUT_FEATURE_BAZ_
much_code();
#endif
With a centralized header defining (or not) hundreds of those #define constants. It's not the prettiest thing in the world, but every time I've worked on a decent sized project, we've used some combination of runtime switches, compile-time constants (this), compile-time compilation decisions (just use different .cpp's depending on the version), and the occasional template solution. It all depends on the details.
While you're the developer just getting the thing working in the first place, though... #if 0 is pretty common if you're not sure if the old code still has value.
Comments are comments. They describe the code.
Code that's being excluded from compilation is code, not comments. It will often include comments, that describe the code that isn't being compiled, for the moment.
They are two distinct concepts, and forcing the same syntax strikes me as being a mistake.
I'm editing this because I'm in the middle of a sizeable refactor and I'm making heavy use of this pattern.
As a part of this refactor, I'm removing some widely-used types, and replacing them with another. The result, of course, is that nothing will build.
And I really hate spending days fixing one issue after another in the hope that when I'm done everything will build and all the tests will run.
So my first step is to #ifdef-out all the code that won't compile, and then to [Ignore] all the unit tests that call it. With this done everything builds and all the non-ignored tests pass.
The result is a lot of functions that look like this:
public void MyFunction()
{
#if true
throw new NotImplementedException("JT-123");
#else
// all the existing code that won't compile
#endif
}
Then I unignore the unit tests, one at a time, and then fix the functions, one at a time.
It's going to take me a couple of days to worth through all of it, and all of these #if's will be gone, before I create the pull request to merge this, but I find it helpful, during the process.
Besides the problem with C-style comments not nesting, disabling blocks of code with #if 0 has the advantage of being able to be collapsed if you are using an editor that supports code folding. It is also very easy to do in any editor, whereas disabling large blocks of code with C++-style comments can be unwieldy without editor support/macros.
Also, many #if 0 blocks have an else block as well. This gives an easy way to swap between two implementations/algorithms, and is arguably less error-prone than mass-commenting out one section and mass-uncommenting another. However, you'd be better off using something more readable like #if DEBUG in that event.
As far as block commenting using // is concerned, one reason that I can think of is that, should you check that code into your source control system, the blame log will show you as the last editor for those lines of code. While you probably want the commenting to be attributed to you, at the same time the code itself is also being attributed to you. Sure, you can go back and look at previous revisions if you need to check the blame log for the "real" author of the code, but it would save time if one preserved that information in the current revision.
That's pretty idiomatic C right there. I don't see what's so wrong with it. It's not a beautiful piece of code but it's easy to read and is clear what's going on and why, even without context.
The variable names could be better, and and it'd probably be safer to use snprintf or perhaps strncpy.
If you think it could be better, what would you prefer it look like?
I might make a slight change:
char username[32];
strncpy(username, 30, (pwbuf ? pwbuf->pw_name : user_id));
username[31] = '\0';
Obviously, everyone has their own opinions on this sort of thing. So here's mine:
I would never write code like the above, and would think less of anyone who did. I can't count the number of times people think it's ok to get away without scope braces, and then been bitten by it.
Putting the control statement on the same line as the code block is even worse; the lack of indenting makes it harder to see the flow control whilst reading. Once you've been coding for a few years, you get used to being able to read and interpret code quickly and accurately, so long as you can rely on certain visual cues. Circumventing these cues for "special cases" means that the reader has to stop and do a double-take, for no good reason.
#if (0), on the other hand, is ok during development, but should be removed once code is "stable" (or at least replace 0 with some meaningful preprocessor symbol name).
Woah there! Don't overreact...
I would call it sloppier for more the inconsistant spacing than anything else. I have had time where I found it better to put short statements on the same line as their IF, though those statements are stretching it.
The inline style is better for vertical brevity... could easily be broken into 4, more lines
if (pwbuf)
sprintf(username,"%s",pwbuf->pw_name);
else
sprintf(username,"%d",user_id);
Personally I hate the next style since it so long-winded, making it difficult to skim a file.
if (pwbuf)
{
sprintf(username,"%s",pwbuf->pw_name);
}
else
{
sprintf(username,"%d",user_id);
}
points above noted. But monitors being widescreen and all, these days, I sort of don't mind
if (pwbuf) sprintf(username,"%s",pwbuf->pw_name);
else sprintf(username,"%d",user_id);
Always seem to have too much horizontal space, and not enough vertical space on my screen!
Also, if the code block already has preprocessor directives, don't use #if 0; if the code already has block comments, don't use /* */. If it already has both, either resort to an editor that has a ctrl+/, to comment out lots of lines. If not, you're stuffed, delete the code outright!
if ( pwbuf ) sprintf(username,"%s",pwbuf->pw_name);
else sprintf(username,"%d",user_id);
Idiomatic and concise. If it got touched more than 2 or 3 times, I would bracket and next-line it. It's not very maintainable if you add logging information or other conditions.
#if 0
....
#endif
Good to turn on blocks of debug code or not. Also, would avoid compilation errors related to trying to block comment this sort of thing out:
/* line comment */
...
/* line comment again */
Since C block comments don't nest.
Very occasionally I use the more concise style when it supports the symmetry of code and the lines don't get too long. Take the following contrived example:
if (strcmp(s, "foo") == 0)
{
bitmap = 0x00000001UL;
bit = 0;
}
else if (strcmp(s, "bar") == 0)
{
bitmap = 0x00000002UL;
bit = 1;
}
else if (strcmp(s, "baz") == 0)
{
bitmap = 0x00000003UL;
bit = 2;
}
else if (strcmp(s, "qux") == 0)
{
bitmap = 0x00000008UL;
bit = 3;
}
else
{
bitmap = 0;
bit = -1;
}
and the concise version:
if (strcmp(s, "foo") == 0) { bitmap = 0x00000001UL; bit = 0; }
else if (strcmp(s, "bar") == 0) { bitmap = 0x00000002UL; bit = 1; }
else if (strcmp(s, "baz") == 0) { bitmap = 0x00000003UL; bit = 2; }
else if (strcmp(s, "qux") == 0) { bitmap = 0x00000008UL; bit = 3; }
else { bitmap = 0; bit = -1; }
Bugs are much more likely to jump straight into your face.
Disclaimer: This example is contrived, as I said. Feel free to discuss the use of strcmp, magic numbers and if a table based approach would be better. ;)
#if is a macro which checks for the condition written aside to it, since ‘0’ represents a false, it means that the block of code written in between ‘#if 0’ and ‘#endif’ will not be compiled and hence can be treated as comments.
So, we can basically say that #if 0 is used to write comments in a program.
Example :
#if 0
int a;
int b;
int c = a + b;
#endif
The section written between “#if 0” and “#endif” are considered as comments.
Questions arises : “/* … */” can be used to write comments in a program then why ”#if 0”?
Answer : It is because, #if 0 can be used for nested comments but nested comments are not supported by “/* … */”
What are nested comments? Nested Comments mean comments under comments and can be used in various cases like :
Let us take an example that you have written a code like below:
Now, someone is reviewing your code and wants to comment this whole piece of code in your program because, he doesn’t feel the need for this piece of code. A common approach to do that will be :
The above is an example of nested comments.The problem with the above code is, as soon as the first “/” after “/” is encountered, the comment ends there.
i.e., in the above example, the statement : int d = a-b; is not commented.
This is solved by using “if 0” :
Here, we have used nested comments using #if 0.
I can name a few reasons for using #if 0:
comments don't nest, #if direcitves do;
It is more convenient: If you want to temporarily enable a disabled block of code, with #if 0 you just have to put 1 instead of 0. With /* */ you have to remove both /* and */;
you can put a meaningful macro instead of 0, like ENABLE_FEATURE_FOO;
automated formatting tools will format code inside #if block, but ignore commented out code;
it is easier to grep for #if than look for comments;
it plays nicer with VCS because you aren't touching the original code, just adding lines around it.
#if 0 ... #endif is pretty common in older C code. The reason is that commenting with C style comments /* .... */ doesn't work because comments don't nest.
Even though it is common, I'd say it has no place in modern code. People did it in olden days because their text editors couldn't block comment large sections automatically. More relevantly, they didn't have proper source code control as we do now. There's no excuse for leaving commented or #ifdef'd in production code.
I am just wondering would it be better to do this:
if((fd = open(filename, O_RDWR)) == -1)
{
fprintf(stderr, "open [ %s ]\n", strerror(errno));
return 1;
}
or this
fd = open(filename, O_RDWR);
if(fd == -1)
{
fprintf(stderr, "open [ %s ]\n", strerror(errno));
return 1;
}
Many thanks for any suggestions,
Yuck, split it up. What do you gain by mashing it all on one line? Let's compare and contrast:
Single-line:
Advantages:
Disadvantages: Hard to read, prone to error. (Consider your first revision.)
Multi-line:
Advantages: Easy to read, less error-prone.
Disadvantages:
I think it's clear. :)
"Sometimes putting it on one line makes more sense, for example: while ((c=getchar())!=EOF)"
That's fine, but that isn't the case here. There are times when not splitting it up makes more sense, but in general, don't.
"It saves more vertical space"
If one line is killing your ability to see the function, you need to 1) buy a monitor with a resolution higher than 640x480, and 2) Write smaller functions.
Really, I've never understood that argument for anything, functions should easily fit on any screen, regardless of a one-line difference.
"Multiple lines make it look complex"
Not really, shoving it on one line is arguably harder to read and more complex looking. Splitting things up makes it simpler to process one bit at a time, one shouldn't assume two lines makes it twice as complex.
Several people have argued in favor of the second. I disagree with them. While there was (apparently) initially a minor issue with = vs. == in the first one, I'd argue that it IS a minor issue.
A much bigger issue is that it's all too common for people (especially if they're in a hurry) to skip over the error checking -- leaving out the if (whatever == -1) completely, usually on the theory that what they're working on is quick, throwaway code and checking for the error isn't really needed. This is a really bad habit; I can practically guarantee that every person reading this has seen real code that skipped error checking like this, even though it really, really should have had it.
In code like this, attempting to open the file and checking for an error in having done so should be inextricably bound together. Putting the two into the same statement reflects the proper intent. Separating the two is just plain wrong -- they should not be separated in any way at any time for any reason. This should be coded as a single operation because it should be a single operation. It should always be thought of and coded as a single operation.
The excuses for doing otherwise are, in my opinion, quite weak. The reality is that anybody who uses C needs to be able to read code that combines an assignment with a conditional test. Just for an obvious example, a loop like while ((ch=getchar()) != EOF) pretty much needs to be written as a combined assignment and test -- attempting to test for EOF separately usually leads to code that just doesn't work correctly, and if you do make it work correctly, the code is substantially more complex.
Likewise, with the problem of - vs. ==. Since I didn't see the defect to start with, I'm not sure how much separating the two would have done to avoid problems, but my immediate guess is that it probably made almost no difference at all. Compilers that will warn you when what was supposed to be a condition contains only an assignment have been around for years (e.g. gcc). In most cases, the symptoms are almost immediately obvious anyway -- in short, the fact that you made a particular typo in one part of this posting but not the other doesn't prove (or honestly even indicate) much of anything about the relative difficulty of the two.
Based on that kind of evidence, I'd apparently believe that "not" is harder to type than "immediately", since I just typed "immediately" without a problem, but had to correct "not" (twice, no less) before it came out right in the previous sentence. I'm pretty sure if we went by how often I mistype it, "the" is the single most difficult word in the English language.
Maybe something where the parentheses make the ordering obvious?
if((fd = open(filename, O_RDWR)) == -1)
In this example, I'll join the chorus saying the second method is better.
The tougher case is when it's in a loop, like:
while ((c=getchar())!=-1)
{
... do something ...
}
versus
while (true)
{
c=getchar();
if (c==-1)
break;
... do something ...
}
In cases like that I prefer to do it on one line because then it makes clear what is controlling the loop, which I think overrides the drawbacks of the complex combination of assignment and testing.
Its a style thing - you're not asking a precedence (not presidence).
Many people will argue the latter example is clearer.
The second is better for readability's sake, but I know I do the first too often. The = operator will take precedence, especially since you have it in quotes, allowing the assigned value to be returned & compared by the == operator.
Except for standard idioms -- ones that are so common that everyone immediately gets what you are trying to do -- I would avoid doing the assignment in the conditional. First, it's more difficult to read. Second, you leave yourself open (at least in weakly typed languages that interpret zero as false and non-zero as true) to creating bugs by using an errant assignment operator in the conditional check.
This is a matter of style and is subjective. They do the same thing. I tend to prefer the later because I find it easier to read, and easier to set breakpoints/examine variables in the debugger.
(-1 == __whatever__)
to minimize typo
The first case is very normal when you're writing an input loop, because the alternative is to have to write the input command twice -- once right before the loop, and once right at the end of the loop.
while ( (ch=getchar()) != -1){
//do something with it
}
I think that the second way is more normal for an if statement, where you don't have the same concern.