When error checking in Mu, if there is not a space after #, Mu reports an error:
Block comment should start with a '# '
There is a lot of python code that has been written that does not have a space after a pound sign.
It would be very helpful if this requirement could be turned off.
@ron333,
Thanks for sharing your thoughts.
The motivation behind the "check" button is not only to check for "correctness", helping beginners figure out where their code may have mistakes, but also to advise on coding style, per the PEP 8 - Style Guide for Python Code.
While not "strictly required" for a program to run correctly, Mu strives to guide beginners in learning how to create the best Python code possible, and that includes following the style guide I mentioned above that, in particular, recommends that comments have a space after the # character as better described in this section.
Does this make sense to you? :-)
That said (and I know there is an existing issue for this discussion somewhere...) I do advocate for removing these cosmetic warnings, probably in favour of the new Black-supported "Tidy" button. My own experience of working with kids is that a typical youngsters code will have many of these "You didn't put two blank lines..." kind of warnings which won't actually prevent the program from working.
Obviously, semantic warnings ("you're using a name you haven't declared") are a useful check.
It's good that people learn about things like PEP8 and code readability in general, but I think our current levels of checking are too fussy to be useful in some instances
I don't like forcing students into one single correct code style guideline, it's like trying to give them a single source of truth, which for me is a pretty bad idea. What is good practice today, might not be good practice tomorrow, the world develops, if we lock everything in place, we will not allow ourselves to develop.
I generally encourage my students to clean-up their code, do often peer code-reviews of each others projects, but I also tell them it's up to them to define what they think is nice. The main rule is to be consistent, and do the same thing throughout their programs. I still tell them what is general considered good practice, nowadays.
If I was math teacher I would also teach them the standard version of doing things (e.g. notation for writing intervals), but also tell them that it is not universal, you could make your own syntax and use that if you like, and the notation differs between countries (e.g. on writing intervals), or between different groups of mathematicians (Lagrange, Newton, Leibniz notation, when I went to high school we used Lagrange notation, but now Leibniz notation seems more popular).
So I agree with @ron333, that it would be nice if you could right click on an error and select "ignore", or something similar, if a check doesn't make sense for you. Like if you write in Word, and the dictionary doesn't contain a word, you can add it to your own local dictionary, and don't see the warning again.
Most helpful comment
That said (and I know there is an existing issue for this discussion somewhere...) I do advocate for removing these cosmetic warnings, probably in favour of the new Black-supported "Tidy" button. My own experience of working with kids is that a typical youngsters code will have many of these "You didn't put two blank lines..." kind of warnings which won't actually prevent the program from working.
Obviously, semantic warnings ("you're using a name you haven't declared") are a useful check.
It's good that people learn about things like PEP8 and code readability in general, but I think our current levels of checking are too fussy to be useful in some instances