Programming correctly

Monkey Forums/Monkey Programming/Programming correctly

hardcoal(Posted 2012) [#1]
Knowing a programming language is one thing.
Knowing how to program correctly is another thing.

There are many tutorials teaching the languages of programming.
I'm sure many people would have come with much better results if they knew how to organize there project.
When you make a big project sometimes you collapse in the middle
due to overload of information.
Even big companies suffers from that I believe.

Bottom line. I don't see many tutorial teaching you how to write code correctly.
Maybe in a university you can get that, but it would be nice to see
more tutorials on that subject on the web.


AaronK(Posted 2012) [#2]
I think part of the problem is that a language is a language with a fixed set of rules. Programming styles are as varied as programmers. That said there are great developers out there that teach great programming techniques and paradigms.

Good programmers should know design patterns. If you've been doing it enough you probably invented some of them yourself, but having a good grasp of the established set of patterns is good to have in your arsenal.

I personally think "Clean Code" is a must read as well and most things my Scott Myers are worth reading too.


TeaBoy(Posted 2012) [#3]
I believe that's the beauty of learning - you can always find a better solution to a problem. In terms of coding, I don't believe there is a 'correct' way of coding perse, I believe there are more efficient and organised ways of solving a problem.


Paul - Taiphoz(Posted 2012) [#4]
I got tought some of it at UNI, but for the most part the way I code is the summation of my experience with blitz and now monkey, in essence and ever since blitz3D, I have taken a type/class given it a source file of its own and then any function/method that deals with that type/class will be found in it's source file.

This means that my projects tend to be thin in terms of single file depth but wide in terms of total number of files, and I find that this approach makes it so much simpler to not only bug track, but manage the code.

if for example I have an issue with the player, I know its going to be something in player.monkey, well not all the time but 90% of the time it is.

Now that I am using Diddy, I give each screen its own source file as well, which also makes working with it easy.

I think the reason why tutorials on this are hard to come by, is because like AaronK said, people do it different ways, but I agree it would be nice if there was a central location where people could offer up their project layouts, and descriptions.

I now plan to blog about this at some point, because I think its a very good topic and something I would like to explain in a bit more depth to my son who I am trying to teach.


Fryman(Posted 2012) [#5]
Ive not had any formal programming training from classes or such, Mine started from copying the books onto an Acorn computer when I was really young and just changing things to see what it did.

My recent style reflects what I've seen on the internet, and for monkey due to the lack of the debugger I have looked into Test Driven Development. Im glad I live in an age where information is so easily available.

My style seems to be similar to yours Taiphoz, I have files for each class and one for my tests.

In my pizza game I used a separate file for loading graphics but im not sure this is something I will stick with.

I always worry when I post code online that due to my lack of knowledge of standards it would be met with a lot of criticism and negativity.


Paul - Taiphoz(Posted 2012) [#6]
.


frank(Posted 2012) [#7]
@Fryman If putting code online for others to study is met with criticism you should see this as compliments and learn from it to improve yourself and your style (or not). If it's met by negativity you should ignore it; it's just jealous people who suck.

People will generally be happy if you show something of your work and most people write crap code anyway even if they think they are they are the master ninjas.


dawlane(Posted 2012) [#8]
Knowing how to program correctly is another thing.
There are many styles of programming out there. In my opinion programming is basically the manipulation of data. It's then is just a case of working out what is the best/most efficient way of handling that data.
In the old 8 bit days when you wanted speed you had to learn about the machine you were programming for and the CPU's instruction set. In many cases the CPU's instruction set would have a few powerful instructions that would take quite a few clock cycles to complete but only take a few bytes in memory. Many of these instructions could be written in code and take a few clock cycles less but would use more memory. Then there was how to store the data as memory was limited so the programmers had to figure out the best way to store that information. One of the best examples is probably Jet Set Willy II room format. Another optimisation was to try and cut down on how many function calls were made in a loop. If the function was only a few bytes it made more sense to in-line that piece of code.
In this day and age there are optimising compliers that do most of the work for you. And as mobile devices could be considered the "new" 8 bit computers of the modern world, many of the things learned back in those days would be useful again.

I have taken a type/class given it a source file of its own and then any function/method that deals with that type/class will be found in it's source file.
I also do it that way as well. Makes life a lot easier keeping track of things.


hardcoal(Posted 2012) [#9]
I believe in finding the right pattern and then working according to it.
Finding the right pattern sometimes hard but worth the effort.

What I'm saying is maybe unclear but in time I will explain my meaning.


dawlane(Posted 2012) [#10]
@hardcoal: Is your question how to program or how to devise, design and organise a project?


hardcoal(Posted 2012) [#11]
How to program is also how to devise and organize.
maybe i didn't use the right title.. English is not my language.

I mean how to manage a project correctly.
but that's a part of programming no?

I raised this Issue because no one did before.
Everyone wants to know commands but many are getting stuck
on the faze of building more complex projects so just wanted to say
there is a place to show how each programmer manage his projects.


dawlane(Posted 2012) [#12]
Every project is different. But all projects should start with a design document giving an outline of the program. There are a few templates for these documents. The one by Mark Baldwin looks good so have a google for it. Using this document I would flesh out my ideas using a combination of descriptions, drawings, flow charts and pseudo code. When I actually come to coding the first thing is always the media loading and sprite routines using a skeleton loop for testing. Then I would write and test the code for each part individually before writing the main program loop and integrating the other code modules. As how all these bits of code should plug together depends on how each module was designed.

One way is to study other peoples code to see how they did things. There are loads of open source games out there but of course a vast bulk of them are written in C/C++.


AdamRedwoods(Posted 2012) [#13]
on the faze of building more complex projects so just wanted to say
there is a place to show how each programmer manage his projects.


It's a balance between expandable and readable for me. I want my project to be able to grow, but I don't want to get lost in too many class.methods() scattered among files, trying to find bugs.

I tend to do draw the game first on paper. I have a large notebook for these things. Then I make some graphics in Photoshop. I create a 'screenshot' of what I think the game would look like. Then I create a small "test" program which is usually bad coding, but its simple and fun. Then I take each part and clean it up, make the proper class and methods. Lots of comments! Then it grows and grows to many files but usually follows a similar pattern where each class gets it's own file:
- main loop
- player
- enemy
- ui
- map, environment
- utilities: image loaders, save game, etc.

Any bigger and I would get lost.

But-- i have a separate framework that I use to help create things. I think this is essential. It's the 'toolkit' to making games easy and fun to make. Things like atlas loaders, sprite tweens, tile engines, simple gui, etc, etc.

Everyone has their favorite toolkit. Diddy is an example of one, but I have my own i created.


hardcoal(Posted 2012) [#14]
I believe in building an Engine that controls everything.
and that's what I'm doing now.
I've already made 3 versions and each time I started all over...
because I found a better way to make it.

I think all games are assembled from 3 Elements

Functions,Triggers and Objects.

Objects Are Images Sounds Mesh's etc...

I'm also Parenting Objects to be able to make complex Elements.


hardcoal(Posted 2012) [#15]
the real problem of good programming today are Editors.
I find most if not all Editors pretty similar in there concept.

the real problem for me with code editors is that i cant see the whole picture at once.

there for i feel like im picking threw a door hole on my project
and im sure most feel the same.

a normal human being can concentrate only on one thing at a time.
when your working say on a graphical project you can zoom in and zoom out.
but in code you cant really do that. or maybe you can?

im not at the level of building a code editor atm
but my concept would be like an internet browser.
where you see your main Code and pressing a function wont expend it
but will present to the function code on the same page
and by pressing back and forward like you can go in and out of the function and so on..
thats one point.

Another issue is code replacement.
today what we do is search and replace.
this search and replace sometimes causes serious code mistakes.
instead you should have a list for example all your functions
and by renaming the function on the list it will automaticly alocate it
all over your project and rename it.
off course it may ask you first.

there are many more thing i would do to put on an editor.
I do love Blide and Jungle btw what i suggest are just small things
compering to whole the work that being put there.

but thats some points i wanted to share.
and maybe i will..


TheRedFox(Posted 2012) [#16]
Having a shot at Pharo Smalltalk (http://pharo.org) is quite interesting.
Even if you don't write your apps with it in the end it will change the way you program (did for me).

This is a language to be experienced, reading about it will do about nothing.


therevills(Posted 2012) [#17]
a normal human being can concentrate only on one thing at a time.


You can of course, plan out everything before even touching a computer...

today what we do is search and replace.


In modern IDEs like Eclipse and Netbeans etc you can use the refactoring tools which supersede "search and replace", say you want to rename a method you select the method and refactor it to a new name, the IDE then replaces all instances of that method only.


hardcoal(Posted 2012) [#18]
sure therevills you can plan alot before you touch the computer.
but my dream editor (at this point) would be from flowchart to exe


therevills(Posted 2012) [#19]
Have you seen this?

http://vimeo.com/36579366


Neuro(Posted 2012) [#20]
In terms of coding, I don't believe there is a 'correct' way of coding perse, I believe there are more efficient and organised ways of solving a problem.

I agree with this. I've work with someone who focuses too hard on the text-book proper way of coding, and thus losing track of the actual goals of the task. Often times, its better to just keep things simple.


Gerry Quinn(Posted 2012) [#21]
I think ideally you should code as if you are writing a set of libraries for others to use in the future, even if you are just coding for yourself. I.e. your entities (be they classes or functions or whatever) should be well-encapsulated with specifically stated access methods, and properly annotated.

That said, it is possible to lean too much in the direction of perfectionism, and sometimes you may as well just get something working and later refactor it into something more approaching the ideal. The worst coding methodology, after all, is the one that never results in a finished product, however theoretically perfect it may be. Code is messy and will never be as tidy and elegant as you wish it would.


hardcoal(Posted 2012) [#22]
Im always working on libraries and also make docs for any point.
another thing. I make long function names so ill know exactly what it does.

example:

MoveEntityToTheLeftUsingMouse() ;)

etc..

wow therevills nice interesting tnx beside the stupid movie cant be ran forward er


Patch(Posted 2012) [#23]
Learn about best practices, things like Single Responsibility Principle, Law of Demeter, Liskov Substitution Principles, there are loads. Read about them and apply them. Give pair programming a go, ask lots of questions and be humble. It's all about learning and practice at the end of the day.

Descriptive function names are good and can also be a good indication that something is doing too much or doesn't fit. In your case, I think that method is doing too much, what if you stop supporting mouse movements and go keyboard only? Try and abstract further.


hardcoal(Posted 2012) [#24]
lol 'Patch' this function does not exists it was just an example.

I agree you should be humble and not over think your self in life.
the problem for me is i dont have anyone around me who is a programmer.
so I suffer the hard way and waist years going the wrong way sometimes.
and i may still do that i dont know.. but i try..