Best practise

[XtrmJash]

So in the world of programming a lot of people struggle with the concept of best practise. My understanding of the subject is that basically you should always comment anything which will take longer than a minute to read & understand, handle exceptions where appropriate (another vague term, similar to the term best practise), and that code should be as short and efficient as possible, without the code determining functionality which less less than the desired functionality.

So, what do you know about best practise?

I'll go first, with something I've learnt tonight:

When reading memory, if you're reading more than one value which is stored in a struct, you should read it in such a way. For example, if you are reading the entire battle list of Tibia, you should have your own structure which matches your knowledge of the structure in which it was stored, that way you can use things like Marshall.OffsetOf(VariableInStructure), and it will give you the offset from the start of your struct. My understanding is that this is good practise so that when the client updates, you only need to change the affected addresses, that way if, for instance, a new thing is added after CID, you'd normally have to change every other address, using this method you only have to insert another variable into your BattleList structure, and declare its type correctly (int, long, etc).

I think if everyone shares their own knowledge of best practise, it will be useful for everyone to learn from. I'm sure there are things which people know and others don't, and everybody is capable of optimisation in some form *staring @DarkstaR*.

[Wesker]

this is not a practice, this are advices to make the code more readable and of course every1 uses comment lines, i've seen programs with a huge dialog at the start and even a copyright LOL, some others like html comments curse you if you sell it and so on, so damn funny


the best practice is to program, be constant, try to polish your program, then go for another 1, after 6 months check your previous work and try to polish it, and find some stupid shitt that u wrote back then and laughed at it

Programming is just like a math lesson, you need to understand the process, my teacher said "apples with apples ,oranges with oranges, you can't put a melon in there" and that's very true in programming.

http://www.amazon.com/dp/0735619670/?tag=stackoverfl08-20

to be readable for any human you need :

Understandable code ( do not practice loops over loops over loops if,if,if,if,if,if,if,if,if,if,if,if,if that's the most common error)

Don't repeat code (if x = y then, lines after if x = y then {referring to a different thing} then u wont know what ur using)

Before u even draw a button be sure the code is working, if you don't know if it works if it is understandable and then you just put a hole interface to it, you're going to blow

Comment lines are for your personal use, when you learn how to program you won't need any comment line, by the time you get there, you won't even notice that you have comments all over

Dont get stuck in 1 program (since youre in this forum i will assume your only a tibiabot-programmer assuming u didn't use the api, if you did your not much of a programmer, try some other stuff that's program-related, without any profit, such as the lockbits that jo3 tried on hes ripper, the code blequi posted about reading pixels shows he has dig into another things not just tibia, most important dont follow Darkstar advices on league of legends it will get you screwed)

that 1 is on pdf o/ : http://www.2shared.com/complete/fbompgTJ/Code_Complete_2nd_Edition.html

[DarkstaR]

1. Coding With Consistency
Use a code standard and stick to it. It doesn't so much matter what the standard is, as long as it's easily definable, easy to see, and always followed. This means formatting such as tabbing/spacing, brackets on own line or same line, spacing between operators or not, and casing dependent on scope as visibility. This also means, for OOP, sticking to a get/set/call pattern such as "tell don't ask."

2. Knowing Your Language
If you're using an OOP language, don't use structs and global functions which modify them - use classes and member functions.

If you're using C, use C, not C++. If you're using C++, use C++, not C. This is one of the biggest issues I see, even in professional code bases - people mix C and C++. This also goes under consistency.

3. Keep Code Small
Regardless of what language you're using, you code should be small. You shouldn't scope past a nested level of 3-4 inside a function, and most functions should be between 3 and 8 lines. This keeps code clean and makes it read like a book.

4. Complexity V.S. Performance
Know which way to learn and why. If more performance is only achievable by porting the entire code-base to a new language, it might not be worth it (probably isn't). However, if making a change that brings codes from 20 lines to 50 lines saves thousands of cycles per second, it is definitely worth it. If a function is hogging memory and the only way to make it work well is to write a fixed allocation class, it's probably worth it (make that shit re-usable!).

5. Logging
Make fucking logs. End of story.

6. Commentless Code (AKA Simplicity and Verbosity)
If you're using OOP, especially, your code shouldn't need to be commented (at least, not past your core level). Well-written code can speak for itself. If you have a function named getCPHP(), you might just rename it to getCurrentPlayerHitPoints(). Our screens are wider then they were in the 90's, we can afford to make meaningful function names.



For more insight on #3 and #6, read this book (http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882).

[Wesker]

5. Logging
Make fucking logs. End of story.


made me laught


thats also online :D http://www.tud.ttu.ee/material/kallik/JOOP/Clean_Code_-_A_Handbook_of_Agile_Software_Craftsmanship.pdf

[XtrmJash]

this is not a practice, this are advices to make the code more readable and of course every1 uses comment lines, i've seen programs with a huge dialog at the start and even a copyright LOL, some others like html comments curse you if you sell it and so on, so damn funny

Comments are in place to show what is supposed to be happening when code gets complex, that's what proper programmers use them for. Copyright notices are also a requirement in some software, as when a company sells a physical product (e.g some printing electronics, a USB interface, or something which interacts with a computer) they often also provide an API, so that the user can use said API to build their own code. It's even more common practice to supply sample code, which again is the legal property of the company which provided it. If you ever get a job in programming you might one day understand these things, but I highly doubt it.

Also, making code readable? Seriously? You're gonna talk about that? You struggle to make a fucking forum post readable.

I thought you'd ignored me here anyway?


1. Coding With Consistency
Use a code standard and stick to it. It doesn't so much matter what the standard is, as long as it's easily definable, easy to see, and always followed. This means formatting such as tabbing/spacing, brackets on own line or same line, spacing between operators or not, and casing dependent on scope as visibility. This also means, for OOP, sticking to a get/set/call pattern such as "tell don't ask."

2. Knowing Your Language
If you're using an OOP language, don't use structs and global functions which modify them - use classes and member functions.

If you're using C, use C, not C++. If you're using C++, use C++, not C. This is one of the biggest issues I see, even in professional code bases - people mix C and C++. This also goes under consistency.

3. Keep Code Small
Regardless of what language you're using, you code should be small. You shouldn't scope past a nested level of 3-4 inside a function, and most functions should be between 3 and 8 lines. This keeps code clean and makes it read like a book.

4. Complexity V.S. Performance
Know which way to learn and why. If more performance is only achievable by porting the entire code-base to a new language, it might not be worth it (probably isn't). However, if making a change that brings codes from 20 lines to 50 lines saves thousands of cycles per second, it is definitely worth it. If a function is hogging memory and the only way to make it work well is to write a fixed allocation class, it's probably worth it (make that shit re-usable!).

5. Logging
Make fucking logs. End of story.

6. Commentless Code (AKA Simplicity and Verbosity)
If you're using OOP, especially, your code shouldn't need to be commented (at least, not past your core level). Well-written code can speak for itself. If you have a function named getCPHP(), you might just rename it to getCurrentPlayerHitPoints(). Our screens are wider then they were in the 90's, we can afford to make meaningful function names.



For more insight on #3 and #6, read this book (http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882).

That's more like it. Is the logging comment something you've learnt with XenoBot? The log function is endlessly useful to both myself and HolmaN since when he comes on at 2am and asks me "why isn't this working?" I tell him to talk to a cardboard engineer, he comes back 10 minutes later and sends me the logs and script, and I pinpoint the error and correct it... Endlessly useful. I think XenoBot logging is most useful to you since you can just say to people "check Documents/XenoBot/Logs" and they immediately see the words "Error on line number: 16, expected end near if." lol

[DarkstaR]

That's more like it. Is the logging comment something you've learnt with XenoBot? The log function is endlessly useful to both myself and HolmaN since when he comes on at 2am and asks me "why isn't this working?" I tell him to talk to a cardboard engineer, he comes back 10 minutes later and sends me the logs and script, and I pinpoint the error and correct it... Endlessly useful. I think XenoBot logging is most useful to you since you can just say to people "check Documents/XenoBot/Logs" and they immediately see the words "Error on line number: 16, expected end near if." lol

Logging was implemented, just nothing generated or user-visible. Logs were disabled in non-debug builds and they output using OutputDebugString().

But yeah, I learned having user-accessible logs for certain log levels is a very useful thing.

[Wesker]

Also, making code readable? Seriously? You're going to talk about that? You struggle to make a fucking forum post readable.

I thought you'd ignored me here anyway?

i can understand English, read it, and code in it, typing it its a whole different thing, also I'm using an app called ginger (http://www.gingersoftware.com/) is not the best way to do things but it really saves up time.

Just like in league of legends ignoring people is overrated

[klusbert]

Our screens are wider then they were in the 90's, we can afford to make meaningful function names.

Haha so fun and so true, I hate my functions called GetDinfo. Next day GetDinfo ABOUT WHAT!? And what tha fuck is Dinfo?

And if you looking for a easy good language that make it so easy to have a good structure of your code I would say c# everyday.

I programmed alot in vb over the years and my code is just a mess, then I switched to c# and I have a really good structure of my code. Maybe is not only the language, but c# is good for that.

[XtrmJash]

Haha so fun and so true, I hate my functions called GetDinfo. Next day GetDinfo ABOUT WHAT!? And what tha fuck is Dinfo?

And if you looking for a easy good language that make it so easy to have a good structure of your code I would say c# everyday.

I programmed alot in vb over the years and my code is just a mess, then I switched to c# and I have a really good structure of my code. Maybe is not only the language, but c# is good for that.

Didn't think was a screen size issue, in my experience you'd struggle (on the first publically available computers) to get more than 64kb or hard disk space, so considering each character in a function name would be another byte, you were greatly limited, especially if making a text document editor etc, since they would then need space for the thousands of characters they would type in! There were probably multiple reasons though, since a CPU would also have to process the entire chunk of code, and the longer it is the more CPU intensive it would be...

C# is nice, but VB is great for beginners, since it's so widely used and available. Can't beat good old fashioned BASIC though, and storing it on an 8-inch floppy, then after weeks of entering raw code, compiling it only to find that you've missed a single character somewhere and it doesn't work :D

[klusbert]

Yes vb is good, I think jo3 Darkstar started in vb6 then vb.net then leaving it, the bad thing with vb is that it is unlike any other language. And let you do shortcut in your programing, which is not a good practice.

But if you are going to learn vb, do it with option strict on to learn how to use all data types.

@msdn

Visual Basic allows conversions of many data types to other data types. Data loss can occur when the value of one data type is converted to a data type with less precision or smaller capacity. A run-time error occurs if such a narrowing conversion fails. Option Strict ensures compile-time notification of these narrowing conversions so they can be avoided.

In addition to disallowing implicit narrowing conversions, Option Strict generates an error for late binding. An object is late bound when it is assigned to a variable that is declared to be of type Object.

Because Option Strict On provides strong typing, prevents unintended type conversions with data loss, disallows late binding, and improves performance, its use is strongly recommended."