Starting out in programming

[Pegtor]

Hey there just joined here recently, and I started an "Intro to Programming" class this semester.

(Wait for derisive laughter to stop)

Anyway, it's mostly PHP and HTML and entirely web centered, and I've barely got any experience with coding at all and if anyone would care to share some tips I would appreciate it.

[lemm]

http://mitpress.mit.edu/sicp/

[StupidBunny]

My experience with coding started probably ~17 years ago with Beginning Programming for Dummies teaching me Liberty BASIC, which while not terribly useful on its own certainly taught me some basic coding concepts pretty handily. Of course PHP is necessarily different in a lot of ways (I elated PHP 6 years ago, wrote a primitive SQL database, then promptly forgot everything ) but fundamentally I think there's a few things you need to tell the computer to do in any language.

I guess you can do what I did and just search around the plethora of tutorials online for learning PHP. The link lemm posted looks useful for basic coding rules too. HTML is way easy, really not a programming language at all in a sense, so you shouldn't have much trouble with that.

[Lava89]

I do alot more game programming, so I'll try to make my tips more universal (but I'll try to give examples regardless). I also realize this post is knee deep in the TL:DR territory, so I tried to break things up and most of the length of this post is from the examples, so the first paragraph with the bold sentence is in a nutshell what I'm trying to say. So if that makes sense, feel free to move on and not look at the example I gave.

------------------------------------------------------------------------

One thing I found is to code incrementally-- let's say you want to make a menu with buttons and such, I'd first make sure the program is out putting my graphics, then I'd work on each button at a time and test them frequently to make sure they do what you want.

This is an alternative to just coding everything at once and hoping it will work perfectly. This will actually take more time, because if something doesn't work, you'll have to go through each line of code and isolate things anyways to diagnose your problem.

------------------------------------------------------------------------

Another tip, is say you've declared a variable or function, rather just assuming it will do what you want, use some kind of text output to see what that variable or function is doing.

Take for example, I was working on a game that used an inventory and I made a function that allowed me to search for a particular item in the inventory. Rather just assume the function was going to do what I wanted, I tested a few objects first and had the game tell me if it could find that item in the inventory.

This is really helpful because say you want to make another function that depends on that search function (say a function that only allows you to progress in the game if you have a certain item), the new progress function also won't work if the search function won't either.


------------------------------------------------------------------------

Lastly, use lots of functions, I'm not sure how much this applies in web coding, but the point when my code improved so much more was when I started using functions for practically everything. It will make your code easier to manage and edit-- because you can just edit one function as opposed to hunting downing maybe 50 lines of code in a spaghetti string of programming. Also, logically, you can make your code more fluid.

For instance, say you're working on a game does doing certain things if you're near an object in a game. Say, you can only pull a lever if you're next to it. Now on paper, that might sound easy to find, but there's actually alot of math going into it-- like using the distance formula between the player and lever.

Now if you don't use a function for this, and say you have multiple levers, you'll have to repeat alot of code! It might look something like this:

if square_root( (player_x# - lever1_x# )^2 + (player_y# - lever1_y# )^2 ) < 50 and that's just for one lever! Also, notice that I'm using a square root function to even do this. Then for lever2 you'll have to do this:

square_root( (player_x# - lever2_x# )^2 + (player_y# - lever2_y# )^2 ....
square_root( (player_x# - lever3_x# )^2 + (player_y# - lever3_y# )^2 ...etc

Then you still gotta use that for if-then conditions and loops! Or I just write a function, call it near: so it could look like this:

Code: Select all

function near( player, object, threshold) 

dist# = square_root( (player_x# - object_x# )^2 + (player_y# - object_y# )^2 )

return dist# < threshold
end function

This is saying, given a general object, return whether the player is a certain distance away from it (aka the threshold). So making a more general formula in my function allows me to take those lines of code and just write something like:

near(player, lever1, 50), near(player, lever2, 50), etc. I can also use this function for grabbing items as well, because I made it general enough. So I could write:
IF near(Keen, lollipop, 10) THEN score = score + 100

This is much more fluid than writing out the distance formula, and if something goes wrong, I just have to pop open the lid of the function and see what went wrong or what I need to adjust. Also, even if you coded that function horribly wrong, to correct it, you're just changing say 10 lines of code as opposed to changing 10 lines of code times the number of objects you might use that with. Much more manageable with functions!

Hope this helps! Sorry it took so long for me to say it! haha

[Fleexy]

Something nobody's mentioned yet is:

Use a real IDE (Integrated Development Environment). Notepad does not qualify. (Notepad++ is a decent-ish choice if your language has no real IDE.) Debugging tools - breakpoints, watches, edit-and-continue, live variable inspection - are absolutely 100% essential if you're doing a large-scale project. "println" debugging will take forever and make you sad.

It's possible to write bad code in any language, but some languages make it easier than others *cough* PHP. PHP is a nice choice if you want to build something small- to medium-sized fast, but as soon as your project gets large or you need to collaborate, your code will turn into a disaster. For web development, ASP.NET is much more consistent and has far fewer surprise!'s than PHP, though it may take a little more time to get started with.

For desktop development, I personally prefer VB.NET or C#, written with Visual Studio as the IDE. C++ is a good choice for game development (and works with Visual Studio), or you can use Unity, which is also based on .NET.

Good luck in whatever language you choose!

[Lava89]

Those are some great tips Fleexy!

[Commander Spleen]

When it comes to software development, I endorse cross-platform practices. Use SDL, Allegro, OpenGL, Qt, and anything else that can compile on Windows/Linux/Mac/etc. GODOT is a neat free alternative to Game Maker and Unity, and runs on a variety of systems while exporting to even more.

I disagree with Fleexy's preference toward Microsoft products. Though I don't work on anything particulary large scale or collaborative, so perhaps at that point there may be valid considerations to such an end. I also work without an IDE, but Code::Blocks is a pretty cool option that runs on more or less everything.

While you're working on web-based coding, it could be worthwhile checking out Processing. It has a similar syntax to C/C++ and it can export to JavaScript for web use as well as Linux/Mac/Windows.

Of course, QuickBASIC is still the coolest programming language around (one of the few Microsoft products I actually endorse.) And there are now tools such as QB64 and FreeBASIC to make it useful on modern computers.

my code improved so much more was when I started using functions for practically everything. It will make your code easier to manage and edit-- because you can just edit one function as opposed to hunting downing maybe 50 lines of code in a spaghetti string of programming. Also, logically, you can make your code more fluid.

It also makes your code more reusable for other projects, so you don't have to rewrite everything. The overall structure of your programs should also have this nature about it.

Anyway, my main advice for HTML would be to use lots of nested tables. [bloody gurgle]And the <marquee> tag.[/gurgle]

[Pegtor]

Okay thanks! some great tips so far and I see that you guys have gone to the trouble of making sure it's so easy a caveman can do it which I also appreciate.
I've already gotten a portable version of Notepad++ as I'd had the most experience with it of all the before mentioned real IDEs.
Anyway I still can't get away from PHP until I finish the class (in May) but I will investigate better languages as soon as I get the chance.[/i]

[KeenEmpire]

Something nobody's mentioned yet is:

Use a real IDE (Integrated Development Environment). Notepad does not qualify. (Notepad++ is a decent-ish choice if your language has no real IDE.) Debugging tools - breakpoints, watches, edit-and-continue, live variable inspection - are absolutely 100% essential if you're doing a large-scale project. "println" debugging will take forever and make you sad.

To offer an alternate perspective, I loathe IDEs. The so-called "real" IDEs tend to be bloated and inflexible, the problems they solve tend to be domain-specific (so that if you start up another language, what do you tend to do - install and learn from scratch another IDE...).

My preferred form of editing is, instead, on the level of text. An advanced text editing method, like vim's, is applicable not only for most programming languages, but for any other text-based context as well (LaTeX, org-mode, forum posts). Similarly, a highly customizable editor like emacs allows you to tailor the editor to your own habits, leading to a very efficient environment once mastery is achieved.

That said, there are disadvantages to this approach. Some languages are so badly designed that they require an IDE. Java's the big elephant in that room, and is in fact so terrible that most emacs users recommend against editing it in emacs. Personally, I get enraged and avoid any of those languages, but you might not be able to.

With debugging tools, I honestly can't say (I really need to learn more about those; I use IPython but I'm not sure whether that's comparable), but it would not surprise me at all to hear that some IDEs have better integration with at least some of those.

Finally, and most obviously, both vim and emacs have a steep learning curve. Neither are primarily mouse based (though I'd argue, after navigating many an IDE menu that tried to fit in literally every option, that that's a good thing), and both have defaults which are unfamiliar to this generation of computer users (though I'd argue that vim's defaults serve a very strong purpose). It's probably a good idea to wait until you're not busy before trying them out.

So if the defaults predate what we're used to, why haven't new, "updated" versions of, at the very least, emacs taken over? Part of it is inertia. Another part, however, is that many of the well-renowned would-be emacs killers tend to be proprietary, and lose their momentum once their developers go AWOL, the community being unable to fork and pick up the slack. (By contrast, you get many an emacs/vim user expressing their comfort at being able to learn their editor once and use it for decades at a time.) The freedom of your tools is unexpectedly important; otherwise you're left vulnerable either to developer neglect, and/or to them deciding to charge and arm and a leg while messing with backward-compatibility to ensure you're forced to upgrade. For that reason I share Spleen's suspicions toward MS products, along with any products that require a high personal investment, but for which you, or others like you, are not free to work with the code. Better to avoid that trap, IMHO, from the start.

Actually, there is something new, neovim, which promises, among other things, modern scripting languages and embedding into IDEs (presumably to gain the best of both worlds). I'm anxiously awaiting the result.

[MoffD]

Welcome back KeenEmpire!
I must say, your post reminds me of the odd turf war between vi(m) and emacs users. I tend to prefer vi for the cli, although I haven't learned most of emacs' functionality so I can't say which is better for specific applications.

[KeenEmpire]

Thanks! I got hit by nostalgia and decided to come check out the forums.

From what I've gathered, the most relevant difference is that emacs is much more customizable because:

1. It's a Lisp Machine running over a very thin C-layer, unlike vim (and... most everything else, I suppose) which is a C system with some limited plugin APIs.
2. vimscript sucks

In fact, it's so customizable that vim fans have implemented (most of) vim in emacs - see evil-mode. Incidentally, this finally invalidates the joke about emacs being a great OS lacking only a decent editor...

Concerning specific domains: from what I've heard, emacs is often considered the best editor for Lisps (as an aside, I'm guessing the vim model is not quite as useful for paredit, though I wouldn't be surprised if people are trying out variations as we speak), and org-mode. Not sure about any others.

(Note: I say paredit, because the video is cool, but I'm actually using smartparens, because it also works with other delimiters like \left( \right) in LaTeX-mode.)


Oh yeah, another thing I forgot to mention in my previous post: learn about versioning systems (git, svn) ASAP. They are very useful, even for backups not related to programming projects. And, yeah, I need to start on that myself, cough cough.

[Commander Spleen]

geany ftw (minus the IDE stuff--as a straight code editor I've not found anything more comfortable)

[KeenEmpire]

As far as programming goes, I adopt a functional style where possible. John Carmack has given his two cents on the topic.

This means that, in practice, I tend to use:

• Pure functions where possible - if a function only returns a value, and has no side effects or funny I/O business like checking the time, it is easier to predict and test (want to see what a pure function does, whenever? Just call it with the appropriate values).
• Immutable (or, where the compiler doesn't enforce it, immuted) data where possible. Object-Oriented Programming is commonly associated with Big Balls of Mud because the objects being passed around are allowed to be changed in every which way. As a result, reasoning about an object's current value requires keeping track of the entire lifecycle of the object, rather than just tracing back to find its definition. Thanks to the paradigm of retaining and mutating old data, that lifecycle may well have begun a long, long time ago.
• Higher-order functions - if I can specify a large portion of the code path via functions passed as arguments, this allows for more reuse (say, if I want to do something else with the same code path) and more testing (by constructing other test functions)

Unfortunately, not all of these are always feasible. Java, prior to 8, was so limited and/or deep in the object-oriented kool-aid that they didn't even bother including functional constructs that had been known since the 1950s (see the Lisp 1.5 manual). More soberingly, functional programming is often associated with some overhead, so it might be less feasible, for, say, resource-intensive games (though Carmack would know more about that than me). This might be partially mitigated with good design: there are efficient implementations of immutable objects used, for instance, in clojure, and I think some libraries available for python.

Like emacs/vim, functional programming is not necessarily something to learn right away (though it could be if an instructor does it well), but it's something to keep in mind.

[Pegtor]

Well we finally started working with IF and IF..ELSE functions this week (I say "we" but I actually pulled a bit ahead due to storm warnings consistently canceling only my CIS days...long story) so I;m really exited! I think I'll post some examples of stuff I'm working on, so you folks can heckle it into next week for being so easy.