ProgrammingFollow

http://www.sthurlow.com/python/

Good low friction scripting language + beginner tutorial to get you started.

What language is the programming in, Nil? In the engineering program I was enrolled in, we did a lot of MATLAB programming, with the use of Maple's toolbox.

Good Tips for Programming:

1. Give your variables descriptive names: Instead of "x", use "current_balance". In small programs, "x" is sufficient, however, in larger programs, you'll quickly forget what "x","y" and "z" are. I learned that the hard way.

2. Use Comments! Everything makes sense while you're typing away, but don't be surprised when you come back and ask yourself "WTF is this?". Not only does it make it easier for you to remember, it helps your professor know what you're doing or attempting to do.

3. I don't think people actually use flow charts, but don't hesitant to think critically first with a pencil and paper. People program differently. Some like to "freestyle" and think and program at the same time. Others like to think first, write pseudo code first, then program. Find what works best for you and do that.

4. Keep your work! You never know when you might have to refer to something again.

5. Don't reinvent the wheel! There are often already defined methods/classes/ etc. out there. Before you attempt to define it yourself, check to see if one already exists. If you do, ensure that it works the way you intend it to work.

6. For some people, it is more efficient to program in blocks and/or sections. Instead of trying to solve the entire problem at once, break the problem into smaller problems.

7. Test by bits. Make sure you test your code in sections. In coding, if you have an error on line 2, the error might show up on line 40 based on a mistake on line 2. Testing in sections take extra time while coding, but it can save much more time at the end if you're looking for the problem

If your language has built in testing, then test as you go along.

I <3 you JUnit test.

As my Java prof said, writing up test code is annoying. But debugging code without the test code is infuriating.

Also, thisIsCalledCamelCase.

youWillLearnToReadItEasily

This is very good advice. Especially in classes, use both of these and a lot of coding time will be saved. The semi-colon in C languages are elusive beasts though.

These are all good suggestions so far. Make note of them. A few more of my own.

1. Try programming. If you find it interesting though frustrating, stick with it. if you find it annoying or boring, it won't ever get better and get out of it as soon as you can. You either like programming, or you hate it, and it really depends on the structure of your brain and how you look at the world as to which type of person you are.

2. Figure out which program language you are going to be working with, and then look for a good editor. For example, the free micosoft visual studio express editions are a very good place to start. http://www.microsoft.com/express

Some people find that better tools help them program, others claim they like a basic text editor and any color coding or code tree management features distract them. I find that those latter people are idiots personally, so find the best tool you can get and start playing with it.

3. Do read up on the tutorials and the structure and "hello world" programs as you start and with your class, but also take a look at program samples. Do a search for whatever language you are working with, and look for code snippets and how people implemented things. you may not follow it all right away, and not all that you find will even be correct so you need to take them with a grain of salt, but I always found that was the best way to get an initial idea of how everything meshes together, and more importantly "why" some of these things that seem useless initially that they are trying to teach you are important later on.

4. writing comments in code isn't just to help you. Its also to help the person 10 years down the line who ends up updating your code figure out exactly what your thought process was.

5. structure is key. the more things you can make identical (column spacing, line spacing, variable capitolization, etc) the easier your job will be.

It really is always the ******* semicolon though

An anecdote related to this.

For a long time, we used a modified version of EQDKP in my Dynamis group, that one of our members tweaked and turned into FFDKP. FFDKP served us well for four years, until suddenly in 2010, it totally stopped working.

Another person poked around the PHP code and found the following bit:



Considering EQDKP was put together in 1999, then yes. Ambitious it was.

Edited, Feb 11th 2012 9:42pm by catwho

Jesus fuck, keep track of all of your curly braces.

I hate curly braces so much

Awesome. Thanks guys!

Bookmarking this thread, I'm going to get cracking soon. Hopefully I'll be a little ahead of the curve by next year. That being said, many of the guys in my class are about 5 years younger than me, and as I understand it they're taught basic programming at 15-16 in schools now.

To expand on this just a bit:

Not all errors will be due to the raw code itself. I don't want to think about all the times I've sat with a developer watching him step through the code, having it complete flawlessly, only to have it fail in the real environment. This is where assertions and debugging messages can be incredibly useful.

Be aware of user environment variables for your more complicated, memory-intensive functions. If you need to choke back on the amount of resources your code can use at any given time, there are ways to do that. Certainly be aware of memory buffers (maybe not such an issue with more modern operating systems, but I wouldn't bet the farm on it).

IDE's are nice and all, but I think everyone should start with a text editor and the command line/terminal.

Edited, Feb 12th 2012 9:18pm by Wint

Ruby. If you're going to learn a scripting language learn ruby. <3 irb.