[HamletEagle]

Originally Posted by addons_zz You first post is very nice now, and you change log is very well done But I still recommend to follow this guide line and use patch updates "MAJOR.MINOR.PATCH". There you will find out a well explanation about what it is and why use it. For example, this one: Was supposed to be: But this is fine because is not a patch, is a minor update:

It's up to the coder, stop suggesting such things and posting like this is critical or very important, you are not helping anyone.

[addons_zz]

Originally Posted by HamletEagle It's up to the coder, stop suggesting such things and posting like this is critical or very important, you are not helping anyone.

Do you read the entire post? If it was critical or very important I would say so.

Them you suggest to people keep their code bad naming their variables and doing so without documentation too?

Because these are the next things I am going to do next, recommend the opposite and explain why.

[zmd94]

I appreciate your suggestion. ;)

[addons_zz]

I am very happy I could help you. Once I never new about such thing, then I always created some freak way to naming versions. Later when I find this out, I said, DAMN DAMN DAMN ! It was there all along.

[zmd94]

LOL. \o/

[HamletEagle]

Originally Posted by addons_zz Do you read the entire post? If it was critical or very important I would say so. Them you suggest to people keep their code bad naming their variables and doing so without documentation too? Because these are the next things I am going to do next, recommend the opposite and explain why.

I did not read anything from the page, I am talking about your comment.
Coding style, variable naming, versions format, changelog and so on is really up to the coder. Of course it's nice to have a clean code, with proper names, that's why we suggest it when it is the case, but it's not a requierement for approval(as long as the code is not unreadable things are ok).

About documentation, if someone does not want to leave comments explaining his functions it's ok. Approvers should be able to understand based on the code, but having comments helps for sure. Sometimes, when the code is big and you are not the author, understanding from the first glance the whole code logic and flow is not that easy.

If you want to help him then start by checking the actual code, not his changelog structure, lol :O.

Because these are the next things I am going to do next, recommend the opposite and explain why.

What ?

[addons_zz]

Originally Posted by HamletEagle Coding style, variable naming, versions format, changelog and so on is really up to the coder.

Of course, everything is upper to the coders. But people should not go out there releasing open source code, without thinking about others that eventually latter will end up maintaining the code. Because of that, I recommend/suggest to new coders to follow such approach. Is not helpful to someone latter assuming the code has to practically re-code everything because could not understand was was done by the original author.

Originally Posted by HamletEagle About documentation, if someone does not want to leave comments explaining his functions it's ok. Approvers should be able to understand based on the code, but having comments helps for sure. Sometimes, when the code is big and you are not the author, understanding from the first glance the whole code logic and flow is not that easy.

When I said documentation I am not talking about code commentaries, I am talking about this:

PHP Code:

/**
 * Write debug messages to server's console accordantly with cvar gal_debug.
 * If gal_debug 1 or more higher, the voting and runoff times are set to 5 seconds. 
 * 
 * @param mode the debug mode level:
 *           (00000) 0 disable all debug.
 *           (00001) 1 displays basic debug messages. 
 *           (00010) 2 displays players disconnect, how many remaining, and multiple time limits 
 *                                 changes and restores. 
 *           (00100) 4 displays maps events as: choices, votes, nominations and the current map name at plugin_cfg()
 *           (01000) 8 displays vote_loadChoices() and actions at vote_startDirector
 *           (10000) 16 displays messages related to RunOff voting
 *           (11111) 31 displays all debug logs levels at server console. 
 *
 * @param text the debug message, if omitted its default value is ""
 * @param any the variable number of formatting parameters
 */
debugMessageLog(const mode, const text[] = "", {Float,Sql,Result,_}:...)
{    
    g_isDebugEnabledNumber = get_cvar_num("gal_debug");

    if( mode & g_isDebugEnabledNumber )
    {
        new formattedText[1024];
        format_args(formattedText, 1023, 1);

        server_print( "%s", formattedText )
        client_print( 0, print_console, "%s", formattedText )
    }
    // not needed but gets rid of stupid compiler error
    if (text[0] == 0) return;
} 


There you can observe a code commentary, but it was necessary because that code part could be obscure. Code should not need commentaries, unless such at peculiar cases and others certain situations, when a code has properly variable naming and documentation.

Originally Posted by HamletEagle If you want to help him then start by checking the actual code, not his changelog structure, lol :O.

You are right, but if you read that text, you will understand that a good change log is not just a beautifier. And I didn't know about it, for a long time, then I was just pointing this out to him, because he could be at the same situation as mime. Moreover, I will not start point things at his coding without first to be sure that I am really able to do so. For example, now I am developing Multi-Mod Server, Golden Weapons, the Galileo Reloaded plugin, and the Multi-Mod Manager, where I am applying all my efforts to build the best of best. But until this plugins are finished and approved, and I know that I am really good pawn programmer, I am not going to disturb/bad instruct/teach pawn coding.

However for now, I am developing a tutorial teaching about what I now better, variable naming, documentation and software versioning, using what I am learning while developing. And it will be released after I finished my plugins and get them approved. That is to not release bad guides/material out there.

Originally Posted by HamletEagle Of course it's nice to have a clean code, with proper names, that's why we suggest it when it is the case, but it's not a requierement for approval(as long as the code is not unreadable things are ok).

This is sad, that should a be requirement for approval, because a clean code, with proper names, is a readable code (at least should be, as the tutorial I am developing teaches). So, when I code without it, could be close to be unreadable, i.e:

If this is a small code, not a clean code with proper names, or is a trivial stuff that can be quickly relearned, probability is readable. But even if is readable, it will not be the same pleasure as read a clean, properly named and structured code. However, codes can grow as the times goes on, then if it started wrong, should end wrong, unless it pass throw a refactoring at a despair time. For example, the original Galileo code, was without any doubt, a readable code for its author's Brad, but me, it was like chinese until I started renaming variables, cutting off abbreviations, i.e., refactoring the whole code and including documentation. Now, it is easy to program as it was mime. But that code is far way from done because it is not fully documented and re-factored as my other plugin Multi-Mod Manager that includes 100% documentation and since I know, 0% bad variable naming, but I maybe find some lost one, when I re-inspect it, and when I find some, I rename it immediately.

A full method refactoring example mime (an unfinished and unapproved plugin yet), where I changed this:

PHP Code:

public load_cfg()
{
    new szData[LSTRING]
    new szFilename[LSTRING]

    formatex(szFilename, charsmax(szFilename), "%s/%s", AMX_BASECONFDIR, "multimod.ini")

    new f = fopen(szFilename, "rt")
    new szTemp[SSTRING],szModName[SSTRING], szTag[SSTRING], szCfg[SSTRING]
    while(!feof(f)) {
        fgets(f, szData, charsmax(szData))
        trim(szData)
        if(!szData[0] || szData[0] == ';' || (szData[0] == '/' && szData[1] == '/')) continue

        if(szData[0] == '[') {
            g_modcount++
            replace_all(szData, charsmax(szData), "[", "")
            replace_all(szData, charsmax(szData), "]", "")

            strtok(szData, szModName, charsmax(szModName), szTemp, charsmax(szTemp), ':', 0)
            strtok(szTemp, szTag, charsmax(szTag), szCfg, charsmax(szCfg), ':', 0)

            if(equal(szModName, g_multimod)) {
                formatex(g_fileconf, 192, "%s/%s", AMX_BASECONFDIR, szCfg)
                copy(g_currentmod, charsmax(g_currentmod), szModName)
                g_currentmodid = g_modcount
                server_print("[AMX MultiMod] %L", LANG_PLAYER, "MM_WILL_BE", g_multimod, szTag, szCfg)
            }
            formatex(g_modnames[g_modcount], 32, "%s", szModName)
            formatex(g_filemaps[g_modcount], 192, "%s/%s-maps.ini", AMX_BASECONFDIR, szTag)
            formatex(g_fileplugins[g_modcount], 192, "%s/%s-plugins.ini", AMX_BASECONFDIR, szTag)
            server_print("MOD Loaded: %s %s %s", g_modnames[g_modcount], g_filemaps[g_modcount], g_fileconf)
        }
    }
    fclose(f)
    set_task(10.0, "check_task", TASK_VOTEMOD, "", 0, "b")
} 


Into this:

PHP Code:

/**
 * Loads the config file "voting_list.ini" and all mods stored there.
 */
public load_votingList()
{   
    new currentLine                                [LONG_STRING]
    new currentLine_splited                    [SHORT_STRING]
    new modName                                    [SHORT_STRING]
    new modShortName_string                [SHORT_STRING]
    new unusedLast_string                    [SHORT_STRING]

    new votingList_filePointer = fopen( g_votingList_filePath, "rt" )

    while( !feof( votingList_filePointer ) )
    {   
        fgets( votingList_filePointer, currentLine, charsmax(currentLine) )
        trim( currentLine )

        // skip commentaries while reading file
        if( !currentLine[0] || currentLine[0] == ';' || ( currentLine[0] == '/' && currentLine[1] == '/' ) )
        {   
            continue
        }

        if( currentLine[0] == '[' )
        {   
            g_modCounter++

            // remove line delimiters [ and ]
            replace_all( currentLine, charsmax(currentLine), "[", "" )
            replace_all( currentLine, charsmax(currentLine), "]", "" )

            // broke the current config line, in modname (modName), modtag (modShortName_string) 
            strtok( currentLine, modName, charsmax(modName), currentLine_splited, charsmax(currentLine_splited), ':', 0 )
            strtok( currentLine_splited, modShortName_string, charsmax(modShortName_string), unusedLast_string, 
                    charsmax( unusedLast_string ), ':', 0 )

            // stores at memory the modname and the modShortName
            formatex( g_modNames[g_modCounter], sizeof( g_mod_shortNames[] ) - 1, "%s", modName )
            formatex( g_modShortNames[g_modCounter], sizeof( g_mod_shortNames[] ) - 1, "%s", modShortName_string )

            debugMessageLog( 1, "[AMX MOD Loaded] %d - %s",  g_modCounter - 2, g_modNames[g_modCounter] )

            if( g_is_debug & 2 ) 
            {   
                new mapcycle_filePath                    [SHORT_STRING] 
                new config_filePath                        [SHORT_STRING] 
                new plugin_filePath                        [SHORT_STRING] 
                new message_filePath                    [SHORT_STRING]
                new messageResource_filePath            [SHORT_STRING]
                new lateConfig_filePath                [SHORT_STRING] 

                mapcycle_pathCoder( modShortName_string, mapcycle_filePath, charsmax( mapcycle_filePath ) )
                config_pathCoder( modShortName_string, config_filePath, charsmax( config_filePath ) )
                plugin_pathCoder( modShortName_string, plugin_filePath, charsmax( plugin_filePath ) )
                message_pathCoder( modShortName_string, message_filePath, charsmax( message_filePath ) )

                messageResource_pathCoder( modShortName_string, messageResource_filePath, 
                        charsmax( messageResource_filePath ) )

                lateConfig_pathCoder( modShortName_string, lateConfig_filePath, charsmax( lateConfig_filePath ) )

                server_print( "[AMX MOD Loaded] %s", modShortName_string )
                server_print( "[AMX MOD Loaded] %s", mapcycle_filePath )
                server_print( "[AMX MOD Loaded] %s", plugin_filePath )
                server_print( "[AMX MOD Loaded] %s", config_filePath )
                server_print( "[AMX MOD Loaded] %s", message_filePath )
                server_print( "[AMX MOD Loaded] %s", lateConfig_filePath )
                server_print( "[AMX MOD Loaded] %s^n", messageResource_filePath )
            }
        }
    }
    fclose( votingList_filePointer )
} 


[Klatypaus]

Originally Posted by zmd94 Klatypaus, after tested the plugin many times, there will be no problem if player use the auto-buy scripts in buy zone. This is because if the weapon that they are currectly holding is not the same with current weapon war, the weapon will become unusable or unfunctional.

Yes, I tested the plugin extensively now. Players with autobuy scripts cant buy weapons anymore.
GOOD PLUGIN! I hope the admins APPROVE it

I will get you know if I find anymore bugs

[zmd94]

Nice, Klatypaus. I'm glad you love this plugin.

Just let me know if there are any problems.

[zmd94]

Any suggestions or comments?