Welcome to Pencil Code!
This is a blog about the “what” and “why” behind coding. We’ll be posting 10 steps for better coding, as well as other helpful resources for new programmers.
1. Write code that’s easy to change
2. Use functions to organize your code
3. Put in lots of comments so it’s easy to read
4. Make your code look good: indentation and whitespace help
5. Give your variables descriptive names (like “height”) rather than short ones (like “h”)
6. Don’t repeat yourself: use loops (such as “for” or “while”) instead of copying and pasting code
7. Test it along the way: write a little, test a little, write a little more, test a little more …
8. Plan your program before you start (and get feedback from others)
9. Use version control to keep track of changes and experiment with ideas
10. Be patient and have fun!
In his book Start With Why, Simon Sinek explains how successful companies and leaders appeal to the needs of their customers. First they explain why they do what they do, and then they tell what it is that they do.
Here’s an example from Apple: “Everything we do, we believe in challenging the status quo. We believe in thinking differently.” Then comes the what – the new iMac, the iPod, etc.
The same approach can be applied to code.
Start with why you wrote your code a certain way. Explain why you chose a particular solution over others. Make your reasoning clear to everybody on your team, including future you. The what will come as a result of this effort.
I was working on a JavaScript project recently and got to the point where I needed to write some code that used a few levels of nested loops. As I started writing the loop, I thought about what I could do to make it easier to understand.
As a developer, we have to be mindful of how our code is written. We must consider its readability, simplicity, and maintainability.
I remember hearing an interview with John Carmack many years ago. He said something like this when asked about his programming style:
“I don’t care if other programmers can’t understand my code, as long as they can understand the comments.”
He was being facetious (obviously), but there is a lot of truth in that statement. To me, it means that you should write your code in such a way that it is easy to read and comprehend. When we write code that is difficult for other programmers to understand, we are creating more work for them because they need to figure out what the code does before refactoring or modifying it. If you think about it, writing good comments takes time too. It’s much better if we can just write our code so that it is easy to understand without relying on comments.
Pencil Code is an online learning environment for computer programming that allows children to write code and see the effects immediately, both onscreen and in real life.
Pencil Code allows kids to control robots, turtle graphics, 3D graphics, music, and more.
Pencil Code saves all your work automatically. You can even make programs shareable with friends and family by sending them a URL!
The code must be readable.**
The code should be written in English (or other language) and be accessible to anyone who can read that language.**
The code should use a consistent style across the entire project, including indenting and spacing.**
Comments should be used to explain what is happening at key points in the code. The comment should describe what it happening, and not how it is working. Don’t write comments to explain how a function works; instead, focus on explaining why it works.**
Tabs or spaces may be used for indentation depending on personal preference, but they should never be mixed within the same project. Pick one or the other and keep it consistent throughout the project.**
Any block of code (such as an if statement) will have an opening curly bracket { on the same line as its header, with the closing bracket } on its own line at the end of the block. There will be one blank line between each consecutive function declaration, though this is not necessary within a class definition or other similar grouping of functions.**
Functions should have descriptive names that describe what they do rather than their implementation details (e.g., getData() or playAnimation()); variables should also have descriptive names when possible
1.The first step is to copy the code into a text editor and save it to your computer. Make sure you save it as a .py file, which is the standard extension for Python files.
2.Next, open up IDLE (or another Python IDE). In the new window that opens up, navigate to File>Open, and open the file that you just saved in the text editor.
3.The next step is to run the code by hitting F5 on your keyboard or navigating to Run>Run Module in the menu bar at the top of the window. This will open up a new window with the code’s output.
4.Now, we want to go back to our original code window and type or paste in our own code after the comment block that says “Your code goes here.”
5.When we’re ready to run our new code, we hit F5 again or go back to Run>Run Module in the menu bar at the top of our window. This will re-open our output window with our new code’s output!
6.You can continue this process as many times as you like – just keep adding more and more code between those two lines!
7.Once you’re happy with your program
Coding is a craft. Like any other craft, it’s best learned from people who are good at it. But unlike others, there aren’t many opportunities to learn the basics from master coders. So I’ve spent the last year reading and talking to a lot of people about how they write code. I wanted to distill their experience and advice into a list of practical guidelines for writing better code. Here’s what I came up with:
1. Write code that’s easy to delete, not easy to extend
2. Program like the user is a programmer
3. Program like tomorrow you’ll be the one who has to maintain your code
4. Write code that’s easy to explain to your team
5. Treat architecture as damage and refactor mercilessly
6. Take pride in your craftsmanship
7. Remember it’s just a short trip from genius to madness
8. Don’t live with broken windows (or test failures)
9. Be consistent, even if it means being inconsistent with everyone else
10. Embrace change, even premature optimization is the root of all evil