Ben Carpenter

There are different coding practices I like to cultivate, depending on whether I'm working or playing. When I'm working, trying to hey things done as part of a company or to meet the needs of someone whom I've told I would help, people depend on me and there's a more strict timeframe. When I'm playing, working on fun side projects or just learning new things for fun, no one is depending on the final project and it doesn't need to get finished in a specific timeframe. The differences manifest themselves in a couple different ways: 1. Complications and Unfamiliarity. If I'm working and I gey stuck on a complicated problem or am working in an area I'm unfamiliar with, I should be more ready to ask for help or turn the task over to someone more knowledgeable so it can get done in a more timely fashion with higher quality code. If I'm playing and I run into a complicated problem or an area I'm unfamiliar with, I can stick myself. I can spend tim...

How do you feel about working in strongly-typed languages? I generally like working in a strongly-typed language, at least for bigger projects. As I understand it, there's actually not a really firm definition for "strongly-typed", so I'll just define it as a language where the type of all variables is known at compile time, either explicitly by the variable being declared as such or implicitly by it being assigned a value from another variable which has an explicitly-declared type. There are a few reasons I like strongly-typed languages: 1. You're less likely to get your variables mixed up and use the wrong value for something. For instance, if you have a function that takes two arguments of different types, and you try to pass two objects to it in the wrong order, the code won't compile, and it certainly won't run. In this way, you avoid the grief of getting bizarre behavior due to the runtime environment trying to interpret an integer as a character or...

Clean code. Succinct. Legible. Intuitive. Write your code with others and your distant future self in mind. When you are writing code, please keep it clean. Some nice, well-written code is a beautiful thing. It's easy to tell what it's doing. It's easy to tell what changes can be made so that you can have it do other things. It doesn't force others (or you, if you revisit it down the road) to waste significant brain power trying to wrap their (or your) minds around it. Some things to do to keep your code clean: 1. Use small functions which only do one thing. If a function is getting too big, it means there's too much going on and it won't be easy for a reader to understand what's happening in it. This can be done to taste, but I've been told that around twelve lines is a good max. 2. DRY (a common, though sometimes disputed principle - don't repeat yourself). If you're writing the same code in different spots, it can be hard to maintain. If ...