Hot answers tagged

5

Style50 is a tool packed with the CS50 Appliance, not unlike check50 and connect50. Style50 checks your C source code's formatting, i.e. spaces, indentation, variable naming, etc, and tells you your mistakes so that you can make your code much more readable and clean. To get your file checked by style50, type this on the teminal prompt: style50 <name of ...


3

That applies to Harvard/Yale students only. If you are taking the course via edX, your psets are graded for correctness only. edit to add in answer to comment It's still important to style your code, even if it's not being graded. You can refer to the CS50 Style Guide and also run style50 to check your code. as an example: style50 mario.c


2

Nope, won't hurt a thing. It's just a matter of style, but has no effect on functionality. The common practice though is not to have a space between main and the first parenthesis. If this answers your question, please click on the check to accept. Let's keep up on forum housekeeping. ;-)


2

Consider removing the typecasting, because it is essentially redundant. A char is a one-byte integer; the system does it's own internal "casting". Perhaps rewatch the caesar walkthrough. Starting around 4:45 Zamyla discusses ascii math.


2

Change (int) alphabet to ((int) alphabet). The parentheses won't change the meaning (as typecast has higher precedence than binary minus operator), but they silence style50 (and are my preferred style for typecasts).


2

This output is indeed not very helpful. I guess they create a "properly formatted" version of the script and apply a generic diff tool (you can learn more about those later in the course, in the "similarities/more" problem). Easy solutions coming to my mind would cause serious limitations. It's usually considered good style to add a single space on both ...


1

PEP 8 is pretty clear on that. https://www.python.org/dev/peps/pep-0008/#blank-lines Blank Lines Surround top-level function and class definitions with two blank lines. [...] Do you have an example of where David did that? I found a few examples where he left only one line empty, but none where the function is preceded by a comment. Probably he did not ...


1

I see long parts of code without a comment. style50 tends to notice that too ... When running this code through style50, I see that it complains about the first 2 for loops. Didn't it highlight anything on those lines when you ran style50 speller.c yourself? And to quote Cliff B: If this answers your question, please click on the check mark to accept. ...


1

style50 program.c will test your code against the CS50 Style Guide.


1

There's a bug in the grading, as style50 should not be run for all files. If you give me your github username, I can get your grade fixed.


1

Interesting question. In my opinion, your code is correctly styled. Both of the other answers provide a solution to the problem. But, the real problem is style5050 itself. Again, in my opinion, this is the rare case where style50 doesn't know how to correctly handle this. If you put parentheses around the cast and the var, as blauef suggested, it quiets ...


1

Are you comments like this: ... printf("hello, world\n"); // print greeting ... Or like this: ... // print greeting printf("hello, world\n); ... Nothing really wrong with either, although I think that the latter is the preferred format and I'd argue that it's easier to see what's going on.


1

There are no hard and fast rules on how to split a long test condition. It's mostly about doing what makes sense and what makes it easiest to read. For instance, putting one test condition per line when there are many of them is a good idea. I would never put a line split in the middle of a test condition. Also, indenting the split is definitely a good ...


1

While I am not staff, I can tell you that check50 is the program that does the grading for this course. It doesn't run the style50 check, so you're ok there, but it's still a good idea to address problems shown in style50 so that you become accustomed to automatically formatting your code cleanly. If this answers your question, please click on the check to ...


1

Delete the extra curly braces {} from your first if in your main(), lines 18 and 21. That will solve the indentation errors. Then you just have to add some more spaces in your +'s.


1

I now know what exactly causes the 'failed to parse'. The following statement causes the problem if isupper(plaintext[i]) change the statement to: if (isupper(plaintext[i])) and now style50 works. Adding the extra parenthesis fixes style50. The program will compile and work either way, but style50 only works if the parentheses are surrounding the ...


1

It is anticipating that line 10 is the code for case1, in which case it should be indented. So I would ignore that error.


Only top voted, non community-wiki answers of a minimum length are eligible