SC2Mapster

I don't think we'll have any kind of success enforcing style as far as local variables go. As long as people follow some sense of convention with globals and functions though, we should avoid any trouble with conflicting variables.

Also with additional complexity comes additional mistakes, or it may reach a point where people simply don't want to follow a complicated standard and refuse to comply.

The problem this post tries to address extends to GUI, anyways, as well. There just aren't a whole lot of simple, standalone SC2 libraries, whether GUI or Galaxy. They're hardcoded, or imprecise, or just not usable outside of one specific use.

This isn't really a topic on GUI vs Galaxy anyways. For me, and most of the users of this forum, typing out a function name is just faster than finding it in that horrible GUI list, which makes Galaxy a win. Using SC2 Component Lists, you can edit your Galaxy right alongside the editor in real-time, too.

@Mephs: Go

GUI is also slow, contorted, and mangled with inefficiencies. In the time it takes me to write out some arithmetic in GUI, I could've written a whole function in Galaxy.

In addition, if people agree, I think we should begin using typedef to suggest parameter values.
We could come up with a standard "Types.galaxy" which just has stuff like...

typedef int player_t;
typedef int unitflags_t;

Since this kind of shared dependency couldn't just be included in every library, we could implement a dependency notation, so that the map author knows to include these dependencies ahead of including your library.

Ex:

//#include <Types.galaxy>

This kind of commented C-style include is pretty distinctive and would be a heads up.

Jademus and I have talked about this a lot casually in IRC, but I don't think anyone's ever really made a post about it. The things that make Galaxy strong are it's speed of development, file-based modularity, and support for things such as constants in array declaration.

Probably the strongest plus-side of Galaxy is that we can export individual files as a library for a simple "include" statement, and have someone else using it in seconds. Also, since Galaxy is inherently plaintext, glancing over the library before importing is extremely easy. With the benefit of even the half-broken "static" modifier, we can hide library's internal mechanics and organize our code in a much cleaner fashion.

If we really want to showcase Galaxy like JASS was in WC3, we need to start making our own code in our maps modular, and uploading generic libraries to this forum, or the Assets section of Mapster (don't forget to leave a note here, too!).

So my challenge to you Galaxy programmers is over the next few weeks, to look at your map's code, improve it by modularizing it, and then post the modularized libraries in this forum.

I'll start by listing some libraries I've been working on.

Modified Melee Library based on Phantom Mode, with enhanced configuration options
https://github.com/Motive/LibPhantom
Dialog-based WoW-style action bar GUI drawing
https://github.com/Motive/CortexEngine/blob/master/Common/lib/libactionbar.galaxy

We also need to start standardizing our code. What I've found works for me best is:

Library prefix: libLibraryName_
(Applied to all private/public functions, as well as any variables in the global scope. This prevents collisions with other libraries)
Ex:

void libMotive_EatApplePie();
bool libMotive_IsAwesome();

Constant prefix: c_libNameVariableName
(Applied to any constants in the global scope. This method is consistent with Blizzard's Galaxy coding style.)
Ex:

const int c_motiveAge = 19;
const int c_motiveFlagWantsToEatPie = (1 << 0);