MWWorld::Environment

[Zini]

This is an advanced warning:

As most of you should know, the MWWorld::Environment struct is a central collection of pointers to each mw-subsystem, by which each subsystem can access each others subsystem top-level manager class (which is actually more like a facade).

Currently this struct is handed down to all classes that need it. This works very well in most cases. Unfortunately in combination with a couple of workarounds for the early design slows in the esm components, it gets us into major trouble in a few spots.

Therefore I intent to change this struct into a singleton in 0.15.0. Not overly happy with this solution, but a coder got to do what a coder got to do.

For most of you it should make little difference, but there will be a lot of code changes, which might result in an increased number of merge conflicts for a while.

[Zini]

Currently working on this task. Not going well. Some people are repeatedly ignoring our naming conventions and other coding rules stated in the wiki, which turns what might have been a semi-automated one hour of work into a task that is probably taking me the better part of a day.

Some of these rule violations predate our coding standards, so I can't really complain about them. Others though are of more recent origin.

Somewhat unrelated to this, I found a couple of other places where the coding rules or common sense were ignored. While none of these cases are currently causing any problems, the resulting code is still very dirty and that for absolutely no reason.

Some things I have seen:

- using a macro to define a function (why not use an inline function in an anonymous namespace?)
- adding a function to the global namesapce (again an anonymous namespace would have been the answer)
- lots of using directives (only grudgingly accepted)
- using directives in header files (not acceptable at all)

Sorry, if this posting sounds somewhat rude, but I am a bit pissed off right now.

[ElderTroll]

That's got to be frustrating knowing parts of the code are messy and will eventually need some, if not major, rewriting. You're managing a large team of people with very different skill levels and coding habits. It's stressful for sure, but you're doing a kick ass job and hopefully folks will clean up the code and stick around and get proficient in writing to standard.


I fuck up on just reporting the news. At least you don't have to deal with any code I'd contribute.

[Zini]

Done. Finally. The changes are in the next branch now. If you have any active branches that are not meant for the 0.14.0 release (which should be true for almost all active branches right now), you might want to consider merging next into your branch.

[psi29a]

@Zini: git blame! I think you are doing a great job and that this is just a normal case of 'code review'.

You're dealing with a lot of people on a hobby project in your spare time and I'm sure you would rather be doing other things than fixing everyone's crap. The fact that you are able to do this without meeting in person (to be able to hit them hard with a nerf bat for silly mistakes) is impressive.

Could you provide cut & paste examples of what you mean in the wiki? That could help as well! Have you also contacted those who have written the offending code?

[Zini]

I didn't track who did what. That was not the purpose of the exercise. Actually the purpose was equally venting off a bit of steam and bringing our coding guidelines to attention again, especially the sections about naming conventions and other coding rules.

I just made some additions to points that might have been unclear. I think it would be a good idea, if everybody reads these pages again.