Why I do not like "main()" in the BGE

What about Game()?

Player()

Gun()

Shoot()

Reload()

???

If the script is named ‘player’ then ‘player’ wouldn’t be so much of a good name for the main, because this would give: ‘player.player’. It would give the impression that the ‘player’ script also contains modules which have nothing to do with the player.

Also, it’s not common to use uppercase names for modules. You are free to do whatever you want, but you better use the code conventions for Python (PEP 8), because this will make your code more readable. Modules should have short, all-lowercase names. Underscores can be used in the module name if it improves readability. Class names however should normally use the CapWords convention.

Edit: Also better to name scripts (=packages) with short all-lowercase names.

Yes, it tells me you would main through a door ;).
I on the other hand would open, close, lock, unlock or go through a door.

They would even know it when you call it “Player.execute” (which is at least an operation) or “Player.runAllTheCode” (using your words).

Obviously it does not start a program, so it is not doing what the name implies by “tradition” (see below).

As I said - it does not tell what this code is supposed to do, so it lacks support for the reader.

What player? This code does not mention a player. So why are you adding context that is not there? As far as I remember the example was about a state machine.

In term of actions (of a state machine) -> actions run = perform a run operation -> action.run [for you action.main :D]

Yes, yes, it makes perfect sense. It mains. Your implementation of maining means retrieving an entry, retrieving a state, and then exit. That mains this objects.

I think I still use such a code (in a state machine):


if transition.canTransit():
   transit(transition)

See no need to check the implementation.

I guess you like to see it. Here it comes:


def transit(transition):
   self.currentState.runExitActions()
   transition.runActions()
   self.currentState = transition.nextState
   self.currentState.runEntryActions()

I know that river. I used to live just some kilometers away. .

That is the point: (in clean code) names of a function should describe it’s operation. Something that main completely misses.

And again “main” is traditional the “the main function is where a program starts its execution”. In the BGE the main function is already part of the C++ source. When you use it somewhere else e.g. in a Python controller you break this “tradition” as it does not start a program.

Exactly this is what makes me to “not like main() in the BGE”, because it breaks this tradition. All your arguments that it is a “generic description” are fine (if you really need one). But this point, let me look for another “generic description” that does not conflict with this “tradition”.

These are a bit different. The first three names describes a thing. So I would assume it returns me such a thing (e.g. a game, a player and a gun).
This can be the constructor of such an object, which creates and returns an object (Python behavior).
It can be a function either, but has some drawbacks:
A) it does not describe the operation performed on that thing (a better choice would be getPlayer(), retrievePlayer(), findPlayer() … )
B) in Python it can easily result in (hidden) name conflicts:


# here player is a function
player = player() 
# here player is an object (the object the above call returned)

On the other hand shoot() and reload() describe what they do. As a reader I do not need to look at the implementation or the documentation. I can assume, shoot() makes the object shoot, and reload() makes he object reload.
I check the implementation if I’m interested how it does that. (This is behavior at a lower level.)

E.g. if your wife says: “I go shopping” you know whats going on.
I’m pretty sure you do not really want to know each little detail (grab a shoe, grab another shoe, grab even more shoes, look for a matching bag, … go to the next shop, grab a shoe … )

def main()
Now imagine your wife says “I go main”.

Somebody would say “yep, she performs her main operation”.

I would ask “You do what?”, and she would answer:“grab a shoe, grab another shoe, grab even more shoes, look for a matching bag, … go to the next shop, grab a shoe …”
3 hours later I would know -> she want to go shopping.

OFF TOPIC

This is the least stereotypical thing I’ve ever read, wow! hahahaha, that’s too funny…


ON TOPIC

def main()
Now imagine your wife says “I go main”.

Somebody would say “yep, she performs her main operation”.

I would ask “You do what?”, and she would answer:“grab a shoe, grab another shoe, grab even more shoes, look for a matching bag, … go to the next shop, grab a shoe …”
3 hours later I would know -> she want to go shopping.

With main, it would go more like this,

I would ask “You do what?”, and she would just answer:“Shop”, or if she’s a regular woman, she would say, “Work, Eat, Drive, Groceries” every time she does something different.

What player? This code does not mention a player. So why are you adding context that is not there? As far as I remember the example was about a state machine.

Well doesn’t that prove that those method names are unclear? I think the point was that it’s not really known by what you meant by runActions or executeActions, in any case.

Not really. Names are always context sensitive.

In the context of a state machine (and I did mention it with the example) an action is an operation that gets executed at a specific event (e.g. an entry action gets executed when entering a state). These actions do run, execute, perform or whatever word you like most.

In the context of Blender animation it is a collection of animations channels. These actions get played.

To avoid naming conflicts and confusion you either state the context (state machine or animation) or if the context is ambiguous you specify it in the name e.g. AnimationAction, StateEntryAction.

As we use natural language for naming and we try to use as less words as possible there is a lack of precision in the meaning. Together with different contexts the same words are easily interpreted in a different way (You can see it in the discussion of the word main with goran). This can lead to a complete different meaning for each participant. Please keep in mind each mind carry it’s own unique context around.

But how poor would be our language if everything is unique and precise. Especially English has this wonderful blurring and ambiguity right? or left ;)? [I am now digressing from the topic]

I wrote: “I do not like main()”. You see the arguments why I do think so. This does not mean that I’m right with my opinion (Be sure it will not stop me to recommend to avoid main() ;)). I made these points public because I think a lot of community members do not even think about if it makes sense or not. The discussion gave me some additional arguments to both positions. It is up to the everyone if she/he wants to use main() or pick for another name.

Now everyone knows how to make you get angry – just use ‘main’.:smiley:

Well, one reason i don’t use ‘main’ in my scripts is because i don’t want to hypnotize myself.:smiley: Just imagine ‘main’ is everywhere when you have many scripts.

Doors are typically labeled with the name of the room.

They would even know it when you call it “Player.execute” (which is at least an operation)

Execute who? :smiley:

it does not tell what this code is supposed to do

That’s what makes the name “main” superior (in the context I previously outlined), because unlike “runAllTheCode”, it doesn’t try to describe an operation, and in the context that I previously outlined (OOP, removed from SCA as much as possible), that’s important, because one needs to have an entry point to code that could do anything (including nothing, in some cases).

What player? This code does not mention a player. So why are you adding context that is not there? As far as I remember the example was about a state machine.

You introduced the discussion about a state machine … I assumed you meant entry/exit relative to the overall state machine process, not transitions from state to state.

I don’t see how state transitions are relevant to the topic at hand, but here you go:


def state_A(self):
    operation_A()
    if cond_trans_A_to_B():
        # trans_A_to_B()
        exit_A()
        entry_B()
        self.state = self.state_B


def main(self):
    if self.enabled:
        self.state()

What would you name the entry point into the main operation of a state machine?

I know that river. I used to live just some kilometers away.

The flow of execution is crystal clear. :wink:

That is the point: (in clean code) names of a function should describe it’s operation.

In many cases, yes, but in this case, where a function serves as an entry point to code that could do anything, the name of a specific operation doesn’t make sense.

And again “main” is traditional the “the main function is where a program starts its execution”. In the BGE the main function is already part of the C++ source. When you use it somewhere else e.g. in a Python controller you break this “tradition” as it does not start a program.

If “main” was simply where a program starts, it would be called “start”. It’s called “main” because that’s where execution enters/flows into the main loop of the system in question.

When I say “tradition”, I’m referring to the conceptual heritage of “main”, not the specific technicalities of main in compiled languages.

3 hours later I would know -> she want to go shopping.

Well, let’s assume that she tells you “I’m going shopping”, but then, in addition to shopping, she decides to meet up with me, for … umm, you know, to talk about politics, and stuff …

The word “shopping” doesn’t really describe her overall operations for the day.

:cool: