Forum

> > CS2D > General > The Zen of Creating a good Script
Forums overviewCS2D overviewGeneral overviewLog in to reply

English The Zen of Creating a good Script

10 replies
To the start Previous 1 Next To the start

old The Zen of Creating a good Script

Lee
Moderator Off Offline

Quote
The following information are created based on personal experience and on information learned after interning with MIT, CT, UCLA, Princeton, Xinhua graduates under a rather interesting internship program. Please keep these ideas at heart because they will save you both time and cpu resource.

Part one - DRY - Don't Repeat Yourself

Often times the scripter will find that they have to rewrite the same script times after times after times. This is a bad technique because most scripting languages including lua does a more efficient job if you let it index the memory that it needs dynamically rather then creating them time after time. In this case, Refactor. Not only will it bring the number of lines of code that you need down in the long run, it also gives lua a chance to index only what it needs to. Remember, lua has extremely efficient conditionals (Ifs, Fors, and Whiles) so don't be afraid to use them in abundant numbers if you have to.

REFACTOR - Taking repetitive code out of the source and define it as it's own function/class.

For example, take the following script

1
2
3
4
5
6
7
function hook_say(p, text)
	word = {}
	for v, word_ in ipairs(text:gmatch("[^%s]+")) do
		word[v] = word_
	end
	msg("Your Command is "..word[1])
end

It's okay to leave it like that if you don't need to have the text split into the individual words again. However, if you need to have another hook that also needs to split the text, then you're much better off using the following script.

1
2
3
4
5
6
7
function split(t)
	word = {}
	for v, word_ in ipairs(t:gmatch("[^%s]+")) do
		word[v] = word_
	end
	return word
end

By taking out a part of the logic out from the main function and putting it into a subfunction, you allow that piece of logic to be reused. This is

1) Faster and easier for the scripter
and
2) Faster for Lua and CS2D

If you're prone to be the type to write your own server scripts, you'll be amazed at how much time such a simple measure can help you.

old Re: The Zen of Creating a good Script

KimKat
GAME BANNED Off Offline

Quote
I'm learning slowly. No idea what gmatch is, is that like groupmatch? or something for "words".

It'll take me ages to craft another lua script. Besides I got help from MiroslavR and DC in order to make the ones I've released in files section.

However creating a lua script is easy if you have the knowledge of it. Otherwise I doubt it would be an easy task. However I need to manage these lua things, I've been using lua.org to get knowledge I'd recommend lua.org I learned how to make tables and arrays there. The rest is quite difficult, but you need time to learn and most of all the will power to learn I think that's most important, the Zen(Z) of creating a good script.

old Re: The Zen of Creating a good Script

Flacko
User Off Offline

Quote
I agree totally with what Leegao wrote, functions are more efficient, make your code easier to read and sometimes they might be helpful when you have to debug.

old Re: The Zen of Creating a good Script

Lee
Moderator Off Offline

Quote
KimKat has written
I'm learning slowly. No idea what gmatch is, is that like groupmatch? or something for "words".


gmatch() or string.gmatch() is a function that will seperate the text based on a regex rule. The usual way of using this is

text = "a b c d e f g"
words = {}
for word in text:gmatch("[^%S]+") do
     table.insert(words, word)
end

so for examplt, if the text was "!say abcd"

then the words table will be
{"!say", "abcd"}

In which case the script will take the text variable and split it into a table seperated by the spaces. This is a much more efficient way of splitting text and is way better then using string.sub.

Quote
It'll take me ages to craft another lua script. Besides I got help from MiroslavR and DC in order to make the ones I've released in files section.


Take a look at amx2d, it has all of the necessary tools for you to create your own server script without needing to write too much code. However, if you must use your own script, remember to write a set of commonly used tools first, and then write your script, you'll be amazed at how much less work you'll have to put into. What I am writing now is from my experience writing the amx2d tool kit, my various other projects, and my discussion with various IT/CompSci level professionals.

Here's basically something that you'll have to recognize - any type of programming language is nothing more then words wrapped around mathematics. When you get over this, you'll find that programming isn't as hard as you thought it was.

old Re: The Zen of Creating a good Script

RedPillow
User Off Offline

Quote
Im learning programming myself too, There is no other way to learn it, than reading books, making simple scripts and programs and asking for help.

So after all, Im pretty good at using already written scripts, and modifying them as I wan`t... the problems start when Im trying to make something big from it... but eventually I will get over it.

old Re: The Zen of Creating a good Script

jeepohahyo
User Off Offline

Quote
Yes, the use of subroutines is a really basic design feature that every programmer should try to take advantage of as soon as he or she learned to use them

This is not as much for performance (procedure calls always introduce a very slim overhead), but rather to improve the maintainability of the code. If you found a bug in a function, you just fix it there and then you're done, and don't have to copy-paste the code into several places, maybe forgetting one or doing a mistake during this process. In addition, you can run some tests, which check the return results for several parameters.

But function calls have a little overhead, so you shouldn't put three lines of code in a subroutine, just because they are used in three or four places. Okay, if it makes the code really easier to read, you can, but it's not so likely with such a small portion of code. A function should most importantly be a logically be a single logical unit which is independent from everything.

The performance gain in leegaos example lies more in the caching of the variable "word", as far as I can see (Can't see the other code, but it should be something like words = split(foobar) ). gmatch() is an expensive operation (regex operations always are) and calls to it should be avoided, so if you split a string once and need it a short time after again, you should cache it.
edited 1×, last 15.07.09 11:45:14 pm

old Re: The Zen of Creating a good Script

Lee
Moderator Off Offline

Quote
Jonzku777 has written
So after all, Im pretty good at using already written scripts, and modifying them as I wan`t... the problems start when Im trying to make something big from it... but eventually I will get over it.


The best way of doing this is to forgo the books altogether. Books usually discusses the "What are" features and not the "How to" of writing programs. When I started programming, I've often had this difficulties after reading a book due to the fact that while I knew what each of the functions do, I have no idea how to use them outside of the ways the books described them. Therefore, it's equally important to learn techniques of doing as well.

For example, don't try to "learn" the language by memorizing all of its features. Just remember the 20 or so keywords and look up the rest at http://www.lua.org/manual/5.1/#index And don't be afraid to ask for help.

Also, if anyone tells you that a "real programmer" uses notepad, do not believe them. Their "real programmers" are people who think the mere notion of creating a program is nothing more than being "fancy"

Real programmers uses whatever tool they can find to make their programs as quick as possible. For me, I use http://luaforge.net/frs/?group_id=377 which automatically installs ScItE, which lets me check for syntax errors (they type that are easily fixable).

And I don't know if this helps or not but try to imaging writing a program as writing an essay. Think about whether what you have written makes sense or not, substitute parts whose names are deceptive with their more familiar names. For example, if you see

1
2
3
for word in text:gmatch("[^%S]+") do
     table.insert(words, word)
end

You should think

for every 'word' in the text where the word must be right before a space, add that word into a list called words

which would make much more sense.

@Dicker

Not necessarily, an alternative form of implementing the split function is by using lua's native substring function. The problem of which is:

1) You must write more conditions (and tons of more code - TMK's string.split)
2) The fact that lua's substring functions, while ran singularly creates less overhead, coupled together as a brute-forced search-and-replace algorithm does create more overhead on longer strings

However, lua's extremely efficient and even implementing bruteforce algorithms, I've barely if ever noticed any significant overhead. However, since lua doesn't have a native profiler, I can't be sure of this.

old Re: The Zen of Creating a good Script

RedPillow
User Off Offline

Quote
Lots of text = Heavily-running script
Small amount of text = Lighter-running script

??

If we talk about performance of script.


Oh, btw leegao Im going to pm you after the system works... i got question.
edited 1×, last 16.07.09 12:05:44 am

old Re: The Zen of Creating a good Script

jeepohahyo
User Off Offline

Quote
leegao has written
The best way of doing this is to forgo the books altogether. Books usually discusses the "What are" features and not the "How to" of writing programs. [...] Therefore, it's equally important to learn techniques of doing as well.

One tip, it is normal that you get bored by language specific books. That shows that you are ready for the next step (the recommendations apply for all other experienced users as well)
Get a general computer science book, the most important first-time-lecture would be a book about algorithms and data structures. In my experiences I learned that data structures are much more important to know by heart, because with a well-chosen data structure in a complex design, the algorithms sometimes just fall in place. Of course it is also important to know these especially because they are likely to be more optimized (and researched for advantages disadvantages) than self-devised algorithms.

I hope this advise is not off topic. This topic sounded like a more general programming topic and I hope this fits in.

Quote
Also, if anyone tells you that a "real programmer" uses notepad, do not believe them. Their "real programmers" are people who think the mere notion of creating a program is nothing more than being "fancy"

Real programmers use > butterflies

EDIT: No, don't get me wrong, regexes are fine. I just wanted to tell the others that it is important to know which methods are expensive because you should be able to avoid unnecessary calls. Assigning a value to a variable maybe one time more than needed to make the code easier readable might be way to go, but just doing a gmatch() on exactly the same string twice should never be good.
And a nice side-effect from refactoring code to subs is that beginners begin to avoid that by intuition because the return type is placed directly before their eyes and is so tempting to use instead of a second function call
edited 1×, last 16.07.09 12:06:25 am

old Re: The Zen of Creating a good Script

Lee
Moderator Off Offline

Quote
Dicker has written
Get a general computer science book, the most important first-time-lecture would be a book about algorithms and data structures.


Exactly, however it might be a leap to start off with anything in general compsci so I left that part out. In my experience, high school level CompSci nowadays are pretty much completely Java oriented and nothing at all about Computer Science itself. Self taught programmers nowadays are the real deal.

Quote
Real programmers use > butterflies


There we go, I was just thinking about that xkcd while I wrote that

Quote
And a nice side-effect from refactoring code to subs is that beginners begin to avoid that by intuition because the return type is placed directly before their eyes and is so tempting to use instead of a second function call


Which reminds me of the cat and the boiling kettle. But then again, sometimes humans have less common sense than a battered cat.
To the start Previous 1 Next To the start
Log in to replyGeneral overviewCS2D overviewForums overview