What are the worst Scratch programming practices ?
« Computer Science Education
- Login to post comments
Francois Mazaud
Member
March 23, 2011
I would like to get good programming habits to my students. So, I though about asking the community about Best Practices. But I feel that it will be easier to identify the bad stuff (and then pair it with the holy version). So, what are the worst things that we see in your projects ?
I beleive that those qualify:
- leaving instructions floating in the script zone
- attaching the scripts to the wrong sprite (there we are: I can tell that it is the wrong sprite - but it is much harder to tell the right one, isn't it?)
- undue nesting of conditions
...
thanks,
Whenever possible code should be self documenting and require a minimal number of comments.... (As code gets older these comments will often get copied and then the code underneath modified away from the original meaning). A functional call with a descriptive name is often better than a comment. Having said that, any time you make assumption you should document them with comments... Here is a typical monolithic program with everything in one procedure....It is documented with comments, but compare it with below...
Here is a more modularized approach... The main routine is shorter and you only need to concern yourself with the external calls if there is a problem in that code, and then you have a smaller chunk of code to deal with. Incidentally, this code is just to illustrate a point, it can certainly be improved..
Also if you are using BYOB, do yourself a favor and create this block (it is just a function block named "//" with a text input field):
It will allow you to insert comments in blocks or anywhere.
I'm a little late getting to this thread, but if anyone is still interested...
In my colllege CS courses I tell my students that any time I'm tempted to put a comment in my own code, I take that as a sign that I should rewrite that section of code instead, to be less clever.
This isn't because I don't want program documentation. But I want it to be high-level, a text file separate from the program that explains its data structures, the large structure of the program, the user interface, and so on. Along with reasons, if known, why things are organized this way rather than some other way.
None of that lends itself to inline comments in the code.
As for the other things, I agree with Jens that for kid programmers (up through age 18 or so) there's no such thing as a bad programming practice. There are better programming practices, and sometimes I'll try to teach one to a particular kid. But presenting kids with the sort of list of commandments attempted in this thread just makes programming skool, instead of being fun.
I agree with most of the thoughts about good and bad practices here, except one.
Commenting your code is a practice that is never too early to implement.
Commenting the code makes the code more readable; not only for the coder, but for anyone who reads it.
Have you ever looked at a Scratch project that had no comments in the code? Was you able to follow it; to understand what was happening? I'm sure some people can, but not everyone will be as familiar with the code.
Coding comments also helps the coder throughout their coding processes. Have you ever stopped in the middle of a project, only to find when you came back you had to refresh your memory about what you were doing and what you wanted to do next?
Along with commenting the code, I also have students keep a journal for each project which will contain the basic concept for their project, notes, questions, needs, and a psuedocode workup.
Another great reson for code commenting is your students are using/improving thier language skills.
On Nested If's: I agree with Jens comment: "I'd rather read a stack of simple conditions than a cluttered mess of nested ones." Readability trumps performance in my mind for kids just starting to learn. The question I ask is which better facilitates understanding?
Talking To Yourself (A Good Habit): I like to have kids read their code out loud. Especially when trying to debug a problem. I will also ask them to explain what each tile will do and at times point/draw/explain what will happen when that particular block executes. Early in my career, I had a mentor tell me to "think like a computer" and later in my career I had someone suggest I code out loud to try and understand what it does. I was amazed at how much reading out loud helped me. For one it slowed down my thinking and forced me to focus line by line instead of imagining what the next large chunk of code would do. I was often wrong when I guessed, especially since when I started to guess because it wasn't doing what I expected, I had the wrong mental model/image of what was going on.
First Do the simplest thing possible to make it work, then refactor - Kids are motivated to get someting to do what they want (play a game, imitate Mario Bros, etc). Now the question is once they accomplished what they care about, how do you get them to the "hard fun" and have them refactor (which I will define as: clean up their code to improve readability, reduce complexity and increase maintainabilty)?
Good quesiton, suggestions welcomed ;) As they now have accomplished their goal, what is the point (ie: why should the kids care, if it does the same thing). One way I try and deal with this is if multiple kids are working on the same task and one accomplishes it with a "more elegant" script, is to have the the one kid show their script to the rest of the class. I may then also add specific words and comments as to why I like that script and how it is much better than one I wrote (I always try to make myself the fool as opposed to one of the kids, plus it comes naturally to me ;)
User Defined Procedures/Blocks: Amen. This is really needed. Also something akin to siblings in Etoys where sprites share a common script (but the variable values can be different) would be very useful and avoid the copy and paste we are teaching (a really Bad Habit, I see too often, and I'm not talking about kids I am talking about "professional programmers".)
"What is the best method to obtain the solution to a problem? The answer is, any way that works" - Richard Feynman New Textbooks for the "New" Mathematics.
Stephen, interesting remarks. I like the read-aloud idea, I will try it in my next classes.
Re.First do the simplest .... Yes, it is hard to get the kids to put back their code on the workbench for the sake of "easthetic" improvement. I wonder if I should try to get them to read their code a couple of weeks later, to get them to experience how hard it is to decipher programmer's intentions "from the outside", therefore persuading them that a bit of tyding is useful.
To all: thanks for your contributions - despite my silence I have been watching this and hopefully will incorporate this in my next classes !
I was afraid that a topic like this one would come up sooner or later, and that we're going to indoctrinate kids with what we as adults are considering to be "best practices", a term which in itself suggests an unhealthy dose of ideology.
Whenever I see a project on the Scratch website that truly amazes me, looking at the code is a bit of a downer, because it's usually full of gargantuan run-on scripts, global variables, forever loops and race conditions. But - and that's my point - the project impressed me so much that I wanted to look at its code in the first place. Scratch is cool precisely because kids can produce programmed content right away, without first having been instructed in what to avoid and what to adhere to. Sure, more often that not the code is plain ugly, but - and that's my point - that doesn't stand in their way to create and share.
So, you don't *have* to initialize variables in Scratch. Nothing breaks of you don't, they're initially zero. You don't *have* to use the green flag hat block, in fact, I often don't. Instead you can use - say - a mouse click or a keyboard event to trigger things (and to initialize and reset values). It's okay to leave un-hatted blocks or incomplete stacks "floating" around the scripting area, because you can use them to debug your project (by double clicking on them) or as a quarry for features you might want to add later. It's also perfectly okay to nest conditions if that makes it easier for you to keep track of your reasoning, instead of using - equally(!) - nested predicates.
The "stop script" block's *only* raison d'etre is to terminate a perpetual loop in case a stop condition has been met, surely not to end a script that just plain ends.
What's wrong with using just "if"? Often times you plain don't need an "else" case. So kids produce stacks of if conditions instead of deeply nested If/Else ones. I can make out performance issues with this, but OTOH I'd rather read a stack of simple conditions than a cluttered mess of nested ones.
So, Scratch variables don't need to be "declared" (in fact, they do, when you "make a variable"), but they are not restricted to a certain type, and can store either a number or a string (or, in BYOB, even lists, sprites and blocks). Is it really "bad practice" in the adult world to exchange a variable's value with a differently typed other one? Most modern programming languages let you do this, Scratch itself is written largely that way, and it's awesome (plus, it undoubtely works!) :-)
Most of what's ugly in the Scratch projects I'm talking about is rooted in Scratch's inability to allow for user-defined procedures. This deficiency forces kids into a copy & paste metaphor of creating code which is so hard to edit later on. But I understand that this issue is being addressed by the Scratch Team in their current rewrite for v2.0. Until then, let's not tell kids what's "right" or "wrong" and let's asses other programming languages for why so many of them cannot cope with "child-like" practices that are easily handled by Scratch. Let's press those other languages to become more like Scratch! ;-)
--Jens
I understand your point and pretty much agree with it.
I use these 'best practices' to show students how they can improve their projects. If you cannot convince them that what you propose makes their scripts better, then they will not use it. There is nothing wrong with teaching students to organize and tidy-up things.
I also have another goal in mind. After Scratch, my students move to a non-graphical language in which, for example, indentation and variable types matter. So, I want to make them aware of things issues to help them with the transition.
- Lack of comments in the scripts
- Lack of information to the user regarding what to do
- When errors occur, not only to tell the user so but also how to fix them.
- Forgetting to initialize variables before using them.
- Variable names that do not reflect their contents. (Using i, j or k for counting variables, for instance, is acceptable, but otherwise variable names should be realted to the program and the values they carry)
- Some students prefer to use:
if condition then
end if
if not condition then
end if
Instead of the if/else structure. Using "if/if not" may be acceptable initially, but students should eventually transition to "if/else." Two problems with the "if/if not" are
a) sometimes students do not negate the condition in the second "if" statement, but they write the opposite condition themselves, and they do not do so incorrectly. For example, "If x < 10" and "if x > 10" as the replacement for "else"... the case "x=10" is in limbo.
b) There may be actions in the first conditonal that may also trigger the second conditional. I do not have a "real life" example in mind right now, but the following illustrates the idea.
if x > 10 then
....x = x-5
end if
if x <=10 then
....do something else here
end if
We can easily see that if, for example, x = 12 both conditionals become true!
- Recycling variables to hold different types. (This can be a really bad habit which needs to be fixed before they move on to other languages (like Python) in which variable declarations are not needed, making matters worse.) What I mean with this is that, in some parts of the application a variable holds, say, a number, and later on a string is assigned to the same variable.
- Forgetting the "stop script" block at the end of a script. We know Scartch stops scripts automatically, but since the block exists, we should use it. My hope is that getting used to ending scripts with this block will help students in the future remember to close open files, close socket connections, close database connections, etc. (I can dream, can't I)
If I can think of something else, I will post it.
Thanks
Hi Angel,
I have never required my students (grades 3-6) to use the comment part of Scratch becuase I didn't like how they were displayed and I think students would have a hard time explaining their code beyond reading through their blocks. What age group do you work with? How do you introduce comments?
Also, I have never thought to instruct students to use the stop script block when their code naturally ends. Mostly, because a lot of what my students create .. never ends. It is an interesting thought though. Do you explain that it stops anyways? How do you go about explaining the need for this block? I have thought of stop script more of a break statement and not a file close. Maybe I have been misleading myself.
Susan
Hi Susan,
I teach kids quite a bit older than yours.
Using comments can be a great tool to help students plan (design) their scripts once they learn the basics of using Scratch. Think for example of someone learning woodworking: you first learn how to measure, cut, sand, make joints, select wood pieces, etc. Once you have this basic level of mastery, you then move on to know how to make furniture, cabinets, etc. However, you would probably will not start making a chair without at least a basic scketch of what the chair is going to look like, what wood to use, what dimensions and so on.
The way I see it, there are two main kinds of comments students should get used to.
One that we use to explain how something was implemented. The idea here is to communicate to others (or to ourselves, for future reference) about how a fragment of code came to be. Sometimes, we have a complex nested conditional structure, a tricky "repeat until", an intricate broadcasting system, or just a "bunch" of blocks trying to achieve a simple logical task in our program (for example, drawing the outline of a pine tree using the "move", "turn" and the pen blocks in the context of a winter scene). These are all great candidates to be documented. If something took a lot of (trivial) work to achieve, or effort to figure out, it should be documented. (Superfluous comments, however, should be avoided.)
The other kind of comments are related to the planning of the program. These are like the actions in a cooking recipe (e.g., "whisk the eggs and sugar" is a good comment for the set of steps needed to complete this task). I use them to oultine the different (high-level) actions a sprite is going to do. These comments can also be the result of a brainstorming session with the students about what the sprites should do, and in what order. The comments also help in keeping track of what has been implemented, and what is yet to be done. I attach these comments to their corresponding "When" blocks or to the first block implementing the action described in the comments.
It is very tempting to start throwing blocks at scratch and see what it does, and this is Ok when experimenting or learning new blocks. However, whenever you are building an application with the students (in a tutorial, for example), I think it is a good idea to provide an overall picture of what you are trying to do by using comments to describe the high-level actions your application will take.
When assigning projects, you could have the students first describe what they want to achieve using comments. You can then check their "plans" and point out things that are missing, not clear, or just need a different approach.
Other bad programming habits are
1. forgetting green-flag initialization.
A project without green-flag initialization on the scratch.mit.edu website cannot be initialized unless the page is reloaded.
2. run the "change ... effect" without attaching it to a scenario and expect Scratch to remember the setting
Dimitris
- no instructions for the user (in project)
- using wait blocks for dialogue (or other similar situations) instead of message passing
- having multiple sprites in situations where it should be costumes
For scratch beginners the worst problem is the glide block. Its so easy but they they get frustrated that they cant do anything during the guide (not exactly true - but it is much better to do iterative movement).
Definetly, Comments will make it to the list of good habits.
- and I was shown recently that the comments function in Scratch is better than I though :)
I understand the first and third examples -- instances of code being less readable -- but I'm trying to think of an example of the second. :)
I need to think more about what is meant by good programming habits, but something that I feel is often missing that's a good habit is documentation. (Rosemary Slattery also spoke about this at the last ScratchEd meetup.) Whether it's comments with the scripts or a description in the project notes, I feel like some documentation of a project is incredibly helpful and, therefore, a good habit.
K