[OciXCrom]

I guess this doesn't change the functionality of the code, only the way it looks, but I like it. I'll have this in mind for future updates, including other plugins as well. Thank you.

[addons_zz]

Originally Posted by OciXCrom I guess this doesn't change the functionality of the code, only the way it looks, but I like it. I'll have this in mind for future updates, including other plugins as well. Thank you.

You are welcome . Be sure, this does not change the codes functionality, to the computer the styles you use when do you code is irrelevant. This is only relevant to you, the programmer, who has to debug the code eventually. Or even, assume someone's else code. Hence, because of that, there is standards styles that where found to be good and efficient. So is wanted that everybody do follow those guidelines, to avoid such extremes like dispose the whole code and start again. More about those guidelines I discussed at this post here:
https://forums.alliedmods.net/showpo...postcount=1553

[HamletEagle]

Originally Posted by OciXCrom I somewhat know how to use them, but I'm not sure how exactly am I going to accomplish it. Reading the file and creating the tries is probably easy, but I have no idea what to do after the command is executed, since the file is no longer open, but it still needs to be edited.

I did not checked the code after your update, but assuming your old code: You want to edit the file for removing the line, right ? Well, there is no need for this. Just fill the Trie once with all the datas, when player enter the server check if he is in the trie, if so execute the cmd and use TrieDeleteKey to clean the entry from the trie(like you are removing from file). Then, on plugin_end you can do as you do now, open the file, read line by line, check if the identifier is not in the trie, if it isn't this means it should be removed(so if(!TrieKeyExists(trie, key)) { continue } else { fprintf }), if not write the line to the new file, delete the other one and stuff.
This should mimic the functionality.

@addons_zz, this is just up to the coder. Of course we can suggest better naming techniques for variables and hooks, but at the end the coder choose. If you are consistent while coding there are lower chances of getting confused. For example, I was using at the beginning the HN, but got rid of it because it does not make sense in pawn.
I agree, g_ is a prefix that worth, but it is not a requierement or anything.

[OciXCrom]

Later today I'll try to make an "approvable" version of the plugin using that method.

[addons_zz]

Originally Posted by addons_zz This is only relevant to you, the programmer, who has to debug the code eventually. Or even, assume someone's else code.

Originally Posted by HamletEagle @addons_zz, this is just up to the coder. Of course we can suggest better naming techniques for variables and hooks, but at the end the coder choose. If you are consistent while coding there are lower chances of getting confused. For example, I was using at the beginning the HN, but got rid of it because it does not make sense in pawn. I agree, g_ is a prefix that worth, but it is not a requirement or anything.

Sure. You can always to program only for you, or thinking about others assuming you code later. Then when to program you have to think there will be someone's else later someday here improving/debugging my code?

[Arkshine]

Start to learn to name properly a variable, semantically speaking, that's would be a better advice than suggesting the use of Hungarian notation. which is completely outdated way of doing things, horrible in many ways, especially in Pawn which is type less language, that code is simple and short. Also, being consistent is the most important.

[addons_zz]

Originally Posted by Arkshine Start to learn to name properly a variable, semantically speaking, that's would be a better advice than suggesting the use of Hungarian notation. which is completely outdated way of doing things, horrible in many ways, especially in Pawn which is type less language, that code is simple and short.

Hi and sorry about that, you are right, I forget totally about properly naming a variable, and just putting things up his head. And hhahaha, then I'm outdated. Where do I could start and get an update from Hungarian notation? Are you talking about the use of g_ as prefix to global variable? I just think is good for global variables, and end. I am not saying to start using Hungarian notation everywhere, but only in that global case, because:

Originally Posted by Arkshine Also, being consistent is the most important.

Of course, this is vital. And actually I don't use g_ for OOP, as at OOP, classes are concise (should be) and don't have many attributes, as a pawn code is structured and can easily archive a lot of global variables. Hence, I ended up given a bad lesson because I don't explained to him that we are at a structured programming context instead of a OOP.

Our 'finish him' sound:

1. Arkshine and a lot of guys as he says "-which is completely outdated way of doing things, horrible in many ways, especially in Pawn which is type less language", don't recommend you to use g_ for global.
   
2. Me, and some lost others ones, those I see using g_, recommend using it. And I agree, Hungarian notation "is completely outdated way of doing things", except for this g_ case, at strutted programming can grow global variables.

Then here goes the advice I should give at the beginning.

1. CamelCase
2. Naming convention
3. General Naming Conventions
4. Confusing Naming Conventions for Beginners
5. Naming conventions: camelCase versus underscore_case

[Arkshine]

g_ can be replaced with "any variable starting with an upper-case letter is a global variable". g_ is okay but I find it redundant.

[addons_zz]

Originally Posted by Arkshine g_ can be replaced with "any variable starting with an upper-case letter is a global variable". g_ is okay but I find it redundant.

Hahaahahahahaha, I didn't think about that , but I think to let things start with Upper case letter to be OOP classes, but as here don't have such things, then that could be used, but I think it is more reliable g_ instead of start with upper case, because a OOP programmer could think, confuse, "-Hey there is a class here? How?", kkkkkkk

Hence as nowadays most are multi-language programmers and use both structured and OOP languages, just let the Upper Case first latter costume to OOP, to avoid misunderstand about environments. And enforce, now I am at a structured environment, there is anything starting with Upper Case latter.

[Arkshine]

Pawn is not C/C++, what you're saying is really kind of irrelevant. Pawn is a simplified language, no need to think that much. Keep things simple and straight.