Just learning programming, any tips?

[polyx95]

To me, he's just bitching.  I prefer Object Oriented myself, but hey that's me.  What I can't stand is actually procedural.  I mean I get what that guy is saying, but at the same time I really don't care what he is saying.  I was taught OO first, and procedural later.

 

Problem with procedural approach is that it works only for relatively small/not complex projects, if you want to make a distributed system of any complexity the functional approach is the way to go because of the guaranties you get with it.

 

As far as OP's question goes I think the best way to go about learning programming is find a (real!)problem to solve, the real part is important here because it will give you extra motivation. Since you know java perhaps try getting into android development there are plenty of android programming courses(coursera etc.)

[cubercaleb]

Problem with procedural approach is that it works only for relatively small/not complex projects, if you want to make a distributed system of any complexity the functional approach is the way to go because of the guaranties you get with it.

Tell that to Casey, who's software is widely used in the game industry.

[cubercaleb]

To me, he's just bitching.  I prefer Object Oriented myself, but hey that's me.  What I can't stand is actually procedural.  I mean I get what that guy is saying, but at the same time I really don't care what he is saying.  I was taught OO first, and procedural later.

OO code literally does nothing for you. The idea that is makes code less complex is absurd, the complexity is still there, it just spreads it out more than it typically would be in a procedural language like C, great, what does that do for you... ohh wait, almost nothing. There are many other problems with OO, but I won't go into them.

 

For the record, OO is mostly rejected by game developers.

[Art Vandelay]

I'd recommend learning how pointers work at a low level. I found that was really useful in actually understand what was happening underneath the code.

 

Learn what things you should not bother optimizing. e.g. if your compiler is competent, optimizing "foo(std::max(a, b ),std::min(a, b ));" is probably pointless. One of my profs had that specific example in his slides. I tried compiling and testing it and the difference between the "optimized" alternative was less than the margin of error. The assemblies produced were very different looking, interestingly enough.

 

Read about basic data structures, like stacks, queues, BSTs, hash tables, etc.

 

Learning how assembly works is a nice skill to have when you get told "we lost the source code. go fix it" and they don't want to buy you a license for reflector or whatever... hopefully that situation won't come up. Assembly is fun anyway.

 

 

Learn how to use a debugger.

I'd also recommend learning how to test without the debugger. I've worked at places where I had to figure out why something worked on one server, but not the server they didn't give me access to.

 

 

OO code literally does nothing for you. The idea that is makes code less complex is absurd, the complexity is still there, it just spreads it out more than it typically would be in a procedural language like C, great, what does that do for you... ohh wait, almost nothing. There are many other problems with OO, but I won't go into them.

 

OO is nice when you want to have a generic method that acts upon any class or struct that has certain properties e.g. if I have two different trees, both with left_child, right_child and data fields and I want one method that can iterate both trees and print their data.

In a language like C, you have to use preprocessor generics, which don't interact with debuggers in a particularly nice way, and the lack of line numbers within them just sucks.

 

OO is also nice if you want to have a class/struct that can store information from different types.

In C, you can do the above or you can use void pointers, but void pointers also don't tend to interact particularly well with most debuggers I've used. In something like VS, I don't understand why there's no "view as" option for void*.

 

I've personally not found much of a use for things like polymorphism, which people tend to say is one of the strongest features. In every case where it could be applied in my work, I've felt like designing things differently eliminated any need for it.

 

[SSL]

I'd also recommend learning how to test without the debugger.

 

Testing with a debugger? Interesting idea. Obivously, debugging without a debugger, obviously that is a basic skill that goes without saying.

 

What was the place that you worked for with incompetant server admins?

[cubercaleb]

OO is nice when you want to have a generic method that acts upon any class or struct that has certain properties e.g. if I have two different trees, both with left_child, right_child and data fields and I want one method that can iterate both trees and print their data.

In a language like C, you have to use preprocessor generics, which don't interact with debuggers in a particularly nice way, and the lack of line numbers within them just sucks.

Ehem, function overloading.

[d1screet]

I'd say that having a good sense of style is what many beginners tend to overlook.

 

Document everything in a meaningful way; even if you weren't going to expect anybody to read your code, you should still craft your code in a way that's easy to read.

 

Additionally, be consistent with your code; Don't do things like mixing tabs with 4 spaces, nor hacking code together in the hopes that it simply compiles.

 

Google's style guides for certain languages such as Java, C++, and Python are good places to start, but they're not the end-all, be-all. You can adopt other styles as long as you keep things consistent throughout your code,

[Art Vandelay]

Testing with a debugger? Interesting idea. Obivously, debugging without a debugger, obviously that is a basic skill that goes without saying.

 

What was the place that you worked for with incompetant server admins?

I wrote that when I was tired, I meant debug without the debugger.

 

I test with a debugger once in a while. Just put a breakpoint somewhere and make sure the value is right. It's only practical if you won't need to test whatever you're testing again.

 

I've heard that kind of story from several of the other co-op students at my university. It seems unfortunately common. 

 

 

 

Ehem, function overloading.

Honestly, I don't see why you wouldn't just add a different suffix for different parameters. I guess it kinda looks a bit prettier with overloading...

 

 

I'd say that having a good sense of style is what many beginners tend to overlook.

 

Document everything in a meaningful way; even if you weren't going to expect anybody to read your code, you should still craft your code in a way that's easy to read.

 

Additionally, be consistent with your code; Don't do things like mixing tabs with 4 spaces, nor hacking code together in the hopes that it simply compiles.

 

Google's style guides for certain languages such as Java, C++, and Python are good places to start, but they're not the end-all, be-all. You can adopt other styles as long as you keep things consistent throughout your code,

Name everything with as few letters possible

 

don't comment anything ever

 

redefine basic syntax with the preprocessor

 

use the comma operator everywhere