I saw a number of examples of code today that looked very sloppy. For example, there was code in which the lines ran off the screen, code in which the variable definitions in a let statement were all on the same line, and code in which as many lines in the file were commented out as live.

Code like that is similar to English that is not spell-checked or in which the first letters of sentences are not capitalized. 

When code like that is submitted as complete it says that the person who wrote it does not care about what they are writing.

It's not good to do that in a class, and it's not good to do that on a job.

Code of that sort should not be be approved by the reviewer and will not be certified.

Please take pride in your code. It's your product; it is a reflection of you.

When?

At the start of the class I gave you a page of coding guidelines. Follow them and you'll be in good shape. In addition, the bottom of that page points to a style guide used at Brown.

Besides that, the best way to write well styled code is to follow the examples of other people who write good code. I've given you examples of well-written code every week. The book we used for the first few weeks of the class had well-written code. 

There will  always be disagreements about particular style rules. For example the Brown style guide says one shouldn't start a line with a right parenthesis, e.g., at the end of a function. But I'm not so sure that's a good rule to follow: often it's useful to see where the end of a construct falls.

The fundamental question with respect to well-written code is whether it's easy for other people to read. If it's not, for example, if it goes off the screen, it's not well-written. The easier it is for other people to read your code the more likely it is to be well-written. That's the fundamental style guide.