Jump to content

  • Log In with Google      Sign In   
  • Create Account

Ways to avoid the needs and the musts of global variables??


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
87 replies to this topic

#41 Rubicon   Members   -  Reputation: 296

Like
0Likes
Like

Posted 31 December 2010 - 02:36 PM

Speaking personally, I type it in and then run it. Worked for me for the last 25 years and I think it will continue to work for the next 25.

Quote:
Original post by return0
For all of you advocating globals or singletons, how the hell do you test your code to verify it actually works? How do you write isolated unit tests to check your design makes sense before committing to writing the whole subsystem, and to prevent regressions?

Writing non-shit tests requires being able to check the behaviour of components in specific, isolated contexts, and that requires the ability to mock your collaborators and dependencies; you cannot do that if you are using globals/singletons. You'd have to spin up and configure other full systems, accessed through the global (and roll back this state after every test) - sounds horrid!

It's so much easier just to ask for abstractions for your dependencies. You can create mock implementations in whatever state you want and testing is easy, and you also get a loosely coupled (and generally more cohesive) design.

I have no idea what you just said. Is this related to game development in any way at all?

I have several silly results a day as I just type shit in and see if it worked and it doesn't. But none of these takes >3 seconds of typing to fix and none of them ever causes a long term problem that a colleague couldn't figure out in about 3 seconds again.

If we ever ran into these notional problems that advocates dream up, then we'd probably re-examine our working practices. However they just don't. So we get on with churning out perfectly fine working code and f**k the standards comittees and globals police.

How the hell did we get into a situation where lots of otherwise bright and technical people think that leaving a global variable open to abuse is somehow dangerous and a sin and worthy of a bloody flame war.

And just to finish off, what the hell is a unit test anyway? (rhetorical) I think I can guess and it sounds an awfully tedious way to avoid getting work done to me. If anyone asked me what our unit testing practices were in an interview, the very next thing to happen is me saying "thanks for your time" and handing him his train fare. We don't write unit tests, we write games.

Well, flame on then I guess. I could do with losing another one through sheer weight of numbers, as it makes my future as a game programmer feel ever more safe.
------------------------------Great Little War Game

Sponsor:

#42 return0   Members   -  Reputation: 444

Like
0Likes
Like

Posted 31 December 2010 - 03:04 PM

I write a game, but it's also an online service. Deploying failure is very expensive. I don't mean to be insulting Rubicon, but from your posting I get the vibe that you work for a "waterfall" place.

Edit: I've just re-read your post and noticed the underlying suggestion that I am some kind of "TDD advocate" that avoids work to proletyse about testing - this couldn't be further from the truth. I consider myself a "bad engineer" because I feel I am guilty of cutting test whenever possible, but when you are running a set of online games attempting to deploy new features incrementally, daily, you *need* to be sure you haven't broken things and regressed. It's too expensive to run a big enough QA to pick up the slack automation misses daily! I understand why you're advocating a "just get it done" attitude to newbies, but that doesn't necessarily reflect the state of the job market, or of gamedev today, and I think it's important to balance your experiences with those of others.

#43 Rubicon   Members   -  Reputation: 296

Like
0Likes
Like

Posted 01 January 2011 - 12:39 AM

No probs, I think we've clashed before on similar issues, but I was just having a general rant not a personal attack. Apologies if that's what I sounded like.

I appreciate that there are some mission critical things like you describe and I'm sure unit testing and all sorts of other time consuming things are vital and give a win in the right sphere. Online servers being a classic example. Aeroplane flight dynamics being another!

But in the grand scheme of things, all this talk of unit tests and hyper-tight coding practices etc for normal game development are just ways to miss deadlines and go bust. If you can get a budget that includes that stuff then great, but it doesn't happen to almost all of us and is certainly not an inbuilt feature of general game dev.

EDIT: I just looked up "waterfall programming" as I'd never heard of it. From the precis I found it does indeed sound like how we do things and I certainly see no reason why making that observation would be insulting, so none taken. It's also how every game firm I ever worked with or for does things. Apart from one NY based outfit that did that two programmers for one task thingy and went bust as soon as their VC funding ran out...
------------------------------Great Little War Game

#44 phantom   Moderators   -  Reputation: 7565

Like
0Likes
Like

Posted 01 January 2011 - 01:00 AM

Quote:
Original post by Rubicon
How the hell did we get into a situation where lots of otherwise bright and technical people think that leaving a global variable open to abuse is somehow dangerous and a sin and worthy of a bloody flame war.


Because it happens.

Maybe not where you are because you have a small vetted team BUT in larger companies where the quality of coder varies you can't always assume that everyone is on 'your level'.

I've seen horrible things happen because of globals or indeed because of a 'type it in and make it work' mindset which is why I would advocate avoiding globals and taking the time to make sure things work properly and continue to do so (which is where Unit Tests come in).

The point of this is that those who ARE good enough will be able, with time, spot the cases where "the right way" can be ignored in favour of a solution which works just as well but those who ARENT won't try to do such things and make a mess of it causing someone else (and in my experiance this is me) to have to chase them up to fix it.

While avoiding these things might well work for you the difference is that you've got experiance and you've 'grown' as the compexity of software has increased; new people don't have that benefit, new people in large companies even less so.

#45 Dave   Members   -  Reputation: 1528

Like
0Likes
Like

Posted 01 January 2011 - 01:07 AM

Quote:
Original post by return0
For all of you advocating globals or singletons, how the hell do you test your code to verify it actually works? How do you write isolated unit tests to check your design makes sense before committing to writing the whole subsystem, and to prevent regressions?

Writing non-shit tests requires being able to check the behaviour of components in specific, isolated contexts, and that requires the ability to mock your collaborators and dependencies; you cannot do that if you are using globals/singletons. You'd have to spin up and configure other full systems, accessed through the global (and roll back this state after every test) - sounds horrid!

It's so much easier just to ask for abstractions for your dependencies. You can create mock implementations in whatever state you want and testing is easy, and you also get a loosely coupled (and generally more cohesive) design.


I've not seen a single unit test in the games industry, nor can I see the need for them. Games go out buggy, they always will do, the reason is as much the time constraint as the coding practices. Having said that, unit tests etc are much more realistic and suitable for the business software environment.

#46 Dave   Members   -  Reputation: 1528

Like
0Likes
Like

Posted 01 January 2011 - 01:08 AM

Quote:
Original post by Rubicon
Speaking personally, I type it in and then run it. Worked for me for the last 25 years and I think it will continue to work for the next 25.

Quote:
Original post by return0
For all of you advocating globals or singletons, how the hell do you test your code to verify it actually works? How do you write isolated unit tests to check your design makes sense before committing to writing the whole subsystem, and to prevent regressions?

Writing non-shit tests requires being able to check the behaviour of components in specific, isolated contexts, and that requires the ability to mock your collaborators and dependencies; you cannot do that if you are using globals/singletons. You'd have to spin up and configure other full systems, accessed through the global (and roll back this state after every test) - sounds horrid!

It's so much easier just to ask for abstractions for your dependencies. You can create mock implementations in whatever state you want and testing is easy, and you also get a loosely coupled (and generally more cohesive) design.

I have no idea what you just said. Is this related to game development in any way at all?

I have several silly results a day as I just type shit in and see if it worked and it doesn't. But none of these takes >3 seconds of typing to fix and none of them ever causes a long term problem that a colleague couldn't figure out in about 3 seconds again.

If we ever ran into these notional problems that advocates dream up, then we'd probably re-examine our working practices. However they just don't. So we get on with churning out perfectly fine working code and f**k the standards comittees and globals police.

How the hell did we get into a situation where lots of otherwise bright and technical people think that leaving a global variable open to abuse is somehow dangerous and a sin and worthy of a bloody flame war.

And just to finish off, what the hell is a unit test anyway? (rhetorical) I think I can guess and it sounds an awfully tedious way to avoid getting work done to me. If anyone asked me what our unit testing practices were in an interview, the very next thing to happen is me saying "thanks for your time" and handing him his train fare. We don't write unit tests, we write games.

Well, flame on then I guess. I could do with losing another one through sheer weight of numbers, as it makes my future as a game programmer feel ever more safe.


Well said.

#47 Rubicon   Members   -  Reputation: 296

Like
0Likes
Like

Posted 01 January 2011 - 01:13 AM

Quote:
Original post by phantom
Quote:
Original post by Rubicon
How the hell did we get into a situation where lots of otherwise bright and technical people think that leaving a global variable open to abuse is somehow dangerous and a sin and worthy of a bloody flame war.


Because it happens.
<snip>


You're right that I avoid those environments like the plague, but if there are programmers in an outfit that pass a null into a function which then crashes and they can't figure out why that is and fix it quickly, they should get fired.

I totally get what you're saying, I just think it's overdone. It's just not rocket science to call someone elses functions and if the call breaks, then its the caller's job to find why and fix it.

It's not like I'm advocating sloppy and/or badly labelled/documented code. Just code that does what it says on the tin and upholds the garbage in/garbage out paradigm.

I have worked with a lot of juniors and utter newbies in the past, but again I've never had a problem with any of this stuff, and I'm covering a lot of years here.

Self defensive code and asserts are your friends. Making people type 20 characters each time instead of 3 and doing unit tests does not solve the problem of crap coders being on your team, but it does make the good guys less productive and we all know the "stars" are the ones that get most of the work done. Shit should be arranged around keeping their nose to the grindstone at all times imo.
------------------------------Great Little War Game

#48 return0   Members   -  Reputation: 444

Like
0Likes
Like

Posted 01 January 2011 - 02:57 AM

Quote:
Original post by Dave
I've not seen a single unit test in the games industry, nor can I see the need for them. Games go out buggy, they always will do, the reason is as much the time constraint as the coding practices. Having said that, unit tests etc are much more realistic and suitable for the business software environment.

This attitude is prevalent in people who have worked in traditional AAA games studios on several year development cycle "cliff edge" games, with big manual QA teams. Typically games are released with day one patches with critical bug fixes, then a few patches over the next few months to pick up the slack; if this works for these types of games (and I'm not sure that it does, if you look at the state of the traditional AAA games industry), great.

The problem is for companies working outside of the AAA games sphere. My company runs several small, free to play, microtransaction based games, with a very small team. I've worked in AAA, and the attitudes of many of the old school guys (for whom I've otherwise got a lot respect) just don't work well in this environment. The typical user of one of our games is not a hardcore gamer, and if they've forked out a few dollars for an item in the game, it is unacceptable to them for the game to have, as you said Dave, "gone out buggy".

When bugs inevitably do go out, it's terrifying enough pushing a hot fix out of the door under pressure, knowing that it could break something for hundreds of thousands of paying users; this is compounded massively without tests, as you can't be sure you haven't broken/regressed anything else (if you could be sure, there would be no bug in the first place).

Even outside of bug fixes, the competitive edge for a lot of these types of games is derived from how quickly and with what degree of stability you can iterate on features and push out updates. A stable, well designed (and therefore flexible) codebase is crucial from a business perspective; tests are a tool to help you achieve this.

What does all of this have to do with globals? Globals, and poorly factored code in general hamper flexibility. They intertwine services with their dependencies. They lead to brittle designs that are hard to iterate on safely, and this is bad for the reasons I've mentioned above. This answer to the OP's initial question is a bit more abstract, and I understand why some of you are saying "screw it, use a global and get 'er done", but I think it's important to balance this with some real life experience of a games studio where solid engineering really matters. Otherwise, the OP and other new programmers will end up thinking that the complaints against singletons/globals are unjustified scare tactics from ivory tower academic types who have no place in games. I appreciate that it's unlikely that the OP is going to start running a set of online services, but it's still good to explain this stuff.

OP, have a read of the SOLID Principles. That should help inform your OO design choices (and will probably help you design non-OO code too).

#49 Bow_vernon   Members   -  Reputation: 137

Like
0Likes
Like

Posted 01 January 2011 - 03:13 AM

O thanks man :D I really need stuffs to read. Back then I always 'globalized' things. I left the project for a month and when I look back, things are messy. So now I strive for OO design, unleashing advanced c++ features(that I never used before), and take people's advices. Thanks for all the views.

#50 phantom   Moderators   -  Reputation: 7565

Like
0Likes
Like

Posted 01 January 2011 - 03:38 AM

Quote:
Original post by Rubicon
Making people type 20 characters each time instead of 3 and doing unit tests does not solve the problem of crap coders being on your team, but it does make the good guys less productive and we all know the "stars" are the ones that get most of the work done. Shit should be arranged around keeping their nose to the grindstone at all times imo.


Heres the thing; there has never been a link made between less tying and productivity (in fact, personally, I spent more time thinking than I do writing code) so your 20 v 3 character point is somewhat... pointless.

As for unit tests; the majority of it will be setup in pre-production and it only has an impact on core parts of the game where a change without varifying will cause problems. The testing itself will be either automated or automated with a QA check happening so takes no time away from the coders.

In my opinion the MORE testing, even in a AAA game, the better.

Where I work right now it is impossible to get code into the mainline without a battery of automated tests being run on it.

Typical work flow;
- work and commit code to local branch
- when ready setup a 'publish' from your branch to 'mainline'
- publish enters a queue (and is checked for conflicts with other queued work)
- upon publishing the code is
-- compiled for all target platforms
-- game is booted on target platforms and specific maps/tests are run
- if the compiles and tests past the code/data is commited to mainline
- if they fail the change is backed out and the person who commited the change is emailed with details/core dumps

This maintains stability and ensures you don't get into a situation where by mainline is broken and no one can/should work with it.

If anything however we need more tests to stop the artists submitting clearly broken assets.

#51 swiftcoder   Senior Moderators   -  Reputation: 10369

Like
0Likes
Like

Posted 01 January 2011 - 03:42 AM

Quote:
Original post by Rubicon
Why do you want to remove global variables? Are the uni professors pushing fixes to non problems again
Quote:
Original post by return0
Otherwise, the OP and other new programmers will end up thinking that the complaints against singletons/globals are unjustified scare tactics from ivory tower academic types who have no place in games.
You know, if I knew a single ivory-tower academic type who *had* an opinion on coding practices (beyond documentation), my respect for them would increase threefold.

If you go google for all the "singletons evil" articles from a few years back, you will find that 90% of them are from industry types, not academia. Codebases in academia are generally awful: legacy code mashed together with last year's fad design patterns, in some unpleasant language/API combination that no one has ever heard of [smile]

So before you going blaming good coding practices on academia...

#52 return0   Members   -  Reputation: 444

Like
0Likes
Like

Posted 01 January 2011 - 01:44 PM

I agree, and I think that people who disagree like to attribute what they perceive to be bad advice to some impractical academic strawman. I only mentioned it to cover that base.

#53 Rubicon   Members   -  Reputation: 296

Like
0Likes
Like

Posted 01 January 2011 - 10:37 PM

That'd be me then. I can't begin to guess what goes on in university as there weren't even relevant courses in this stuff when I was the right age.

All I can comment on is what I see new grads pumped full of when they turn up. It seems to me they have all sorts of priorities, but shipping code is somewhere near the bottom (right below debugging techniques). It's an easy stretch to see that lecturers don't actually ship any code, and then I can join up my own dots.

Maybe they just get terrorised by being told that everyone else on their teams won't be able to code for toffee and they'll have to keep coming in on Saturday to fix other peoples' problems or something.

Dunno really, but people have to get this mentality from somewhere that globals in your code is worse than failing lotcheck, and it's certainly not borne in the workplace, as like I said earlier, it doesn't go on in any of the many workplaces I've seen.

(And true enough, I've never worked on mission critical server back ends or flight dynamics, just games)
------------------------------Great Little War Game

#54 Rubicon   Members   -  Reputation: 296

Like
0Likes
Like

Posted 01 January 2011 - 10:49 PM

There's also the odd situation whereby every now and again a holy war starts up over utter trivia. It's globals today. Next week it'll be along the lines of "How can you ship games without even reading the GoF book?". A week later it'll be "How can you ship your game without boost and smart pointers?". We've already skirted along the "How can you ship titles without using agile/scrumm/blah?" and that'll come up again too.

The bottom line is that if someone brainwashed me into adhering to all this crap, I'm willing to concede that my productivity might go up by 1%, maybe. But my productivity is already much higher than anyone elses in most places I've worked at. And massively higher than the kind of guys who want to unit test a particle system. And judging by how little time I spend at other peoples desks, my code seems to be somehow useable also.

The unescapable fact of the matter is that all of us "luddites", the few that oppose the motion in forums, are the ones the producers come running to when the project is in the shit. It really is, I get it a lot. Even right this minute (well, over the holdiday) one guy I worked with in the past is talking to me about sacking his freelance team and getting us to start again from scratch.

"Just get it done" is the most important factor in a programmers make up, but this goes totally unsaid. Well, unsaid by those that don't actually think it's top of the list and are therefore just seat filling drones- and those guys should just do what they're bloody well told.
------------------------------Great Little War Game

#55 ApochPiQ   Moderators   -  Reputation: 16402

Like
0Likes
Like

Posted 02 January 2011 - 10:04 AM

Disclaimer: I am stepping into this thread as a community member, and by the unwritten law of GDNet, I hereby forfeit my ability to exercise any moderator power in regards to this thread or any side discussions that may spin off of it. Should things get ugly, though, I will enlist another impartial mod to come clean up as he/she sees fit, so don't take this as permission to get out of line.


I always find it interesting how arrogance tends to manifest in direct proportion to sheer naivete.



Rubicon, please let me be blunt with you for a moment.

You're probably a decent programmer. Maybe. I don't know, I've never worked with you, never seen your code, only read your advice handed out on GDNet - and that I've rarely found to be worth the cost of the paper it isn't printed on. Maybe you're being honest when you say you're so much better than all your colleagues, I don't know that either. But I don't think you should be parading that around as some kind of justification for your opinions.

Suppose Mozart's ghost were to show up here, and start talking about how he's so much better than all his contemporaries, and how in his opinion all this nonsense about playing successive notes in a consistent key is overrated hogwash. We'd probably all roll our eyes at Mozart and move on. Maybe a few of us would feel compelled to point out that he's a bit of a moron for making such statements in a world where musical theory is extremely well understood. Maybe a couple of us more observant folks would realize that he's basically arguing against something he was tremendously good at doing subconsciously, and therefore consider the whole thing an elaborate troll. Whatever.

In any case, if one of history's greatest and most recognized musical geniuses were to show up and start decrying basic music theory as academic bullshit, do you really think anyone but the most naive and ignorant fool would seriously listen to him?



What I'm driving at is this. You're talking as if you are a remarkable programmer. That may or may not be true. But you also talk as if you can thoroughly discount a lot of things that are proven good theory - and not just by theorists, but by those with practice in the trenches who have seen real code and know the real differences between following these guidelines and breaking them.

I have two questions, both rhetorical, which I'd like you to ponder. First: do you really think you are so much smarter than everyone else, that their input is literally worthless? Secondly, do you really think you can be as productive as you claim without at least instinctively doing things right, regardless of how you think you got there?



It's ironic that you keep worshiping this notion of "just ship code" as if it were so holy and superior to all other perspectives. The funny thing is, I also place a huge emphasis on shipping code. But I think there are some subtle differences in our ideas of what it means to ship.

To you, apparently, it means "kick something - anything - out the door and if you can't understand or fix it by yourself later, then fuck you."

To me, shipping code means four things:

  • Producing work which accomplishes the goals that were set forth for the project

  • Accomplishing objectives in a reasonable - often pre-agreed - time frame

  • Writing code that both I and anyone else can maintain and understand far into the future

  • Taking responsibility for the problems that will inevitably arise and working proactively to prevent or at least minimize them prior to shipping - then supporting and reacting to situations as they arise post-ship


Frankly, I think my idea of shipping code is a lot more professional and respectable than yours. And everyone I've worked under in my career is bound to agree.



I also find it interesting that you mention that people come to you to get the job done.

This is true for me as well.

Except there's a key difference: I get it done according to my (very high) standards, and I do so by embracing the advice of people with more intelligence and experience than myself. I get repeat business because I can prove in any environment that I am good and that my skill merits the investment in my time.

You seem, by your words, to get by sheerly on contrast with the alleged incompetence around you.

I could drop into a studio full of far better programmers than myself and still hold my own and do solid work, and still earn a good reputation, still earn repeat business.


Could you?




Also, you expressed some particularly interesting opinions about automated testing and its relationship to games. Have a look around the job postings for the industry for "SDET" positions. I'm sure you have no clue what that means, so look it up. Be educated.

Just because you're so damn sure of yourself doesn't make you right.

#56 Rubicon   Members   -  Reputation: 296

Like
0Likes
Like

Posted 02 January 2011 - 10:55 AM

*deleted*

I did type a long litany addressing every accusation, but defending myself that way looked churlish and I really don't need to.

If you have it in your head that I'm sort of twat and want to read that much bile from between the lines then be my guest.

[Edited by - Rubicon on January 2, 2011 5:55:23 PM]
------------------------------Great Little War Game

#57 Rubicon   Members   -  Reputation: 296

Like
0Likes
Like

Posted 02 January 2011 - 11:14 AM

Just to summarise:

Yes, I do come across as arrogant at times and I am extremely dismissive of new ideas for the sake of it. Because they're usually shite or address non-problems or are just too damn fiddly to be viable.

However, I've been working in the games industry practically since it started and have never been out of work for a single day. I've shipped about 50 titles over that time. I can think of only two that went out late and one that went out too buggy.

I won't be right all the time, and someone may well have a better opinion on a particular topic than I. But if you think my work record doesn't qualify my opinion on matters as being valid and useful, even if you don't agree with some of them, then what exactly is this board for?

You want the blind leading the blind now?

[Edited by - Rubicon on January 2, 2011 5:14:30 PM]
------------------------------Great Little War Game

#58 swiftcoder   Senior Moderators   -  Reputation: 10369

Like
0Likes
Like

Posted 02 January 2011 - 11:45 AM

Quote:
Original post by Rubicon
I am extremely dismissive of new ideas for the sake of it. Because they're usually shite.
The issue I take with your stance is that most of these aren't new ideas just for the 'sake of it'. Some group of people have distilled a sizeable body of experience, and came up with a few principles that they find make life easier.

Now it may well be the case that your own body of experience does not support the same conclusions, but being openly combative to every, single, new, idea, just for the sake of it, doesn't really sound any better than what you are fighting.

Now, I don't entirely disagree with what you are saying. But as far as I can recall, you have only been on this warpath for a couple of weeks - so may I ask why the sudden conviction to swing everyone to your own viewpoint?

edit: new forum bug - can't link to individual replies, because the postbox interprets hash-prefixed numbers as unicode escapes...

#59 Rubicon   Members   -  Reputation: 296

Like
0Likes
Like

Posted 02 January 2011 - 12:16 PM

I think my tolerance capacitor just fills up with certain things and I need to discharge it once in a while.

I'm only dismissive of this stuff (boost, unit tests, design patterns, multi-inheritance etc) because I *am* ignorant of a lot of it! Or have been bitten by it.

Pardon the arrogance again, but I've been put on the spot: The reason I keep harping on about "just get it out" is that I really do have a reputation for getting done in a day what other experienced guys might take two or three over. It's what I do. Don't come to me for a physics engine as I'm not too hot on that stuff, but do come to me if you want standard stuff punting out at a massive rate. And most of game dev is standard stuff. We use a bought in physics engine for example.

So my point is this. If I truly am faster than average to the point of having a rep for it, and I still don't know how to use boost, don't use agile development, don't do unit tests, then what is all that stuff meant to be achieving?

Regarding the advanced coding stuff, again its more down to practicality than some sort of binary racism. A lot of people attacking my stance seem to fall back to comments about solidity and maintainability and self defence, and that's a fair argument.

However, if you strip away templates, multi inheritance, excessive operator overloading, boost, etc then the code becomes so simple to look at that a newbie can fully understand everything I wrote after a quick scan - and that's the best sort of maintainability you can have in my book. Sure the lack of templates can cause extra work, but someone already said that the actual typing isn't a big part of your day and I agree. So it's not much work to just drop them and keep your code readable by anyone then, is it.

And finally, the reason it winds my up when someone says "you're wrong, industry experts have said this..." is because I consider myself to be that soldier too. When we started our own company we made all these things above illegal in our coding practices and still got lots of good work done on time for good profits. And our code is never a problem to port, is always readable and is regularly maintained. So it's a proven, viable operating practice whether that goes against the grain or not.

And that's just not just meant as "bully for me". The point of the above is again purely practical. We get shit done on time and to budget without all the new this and that, so for newbies just starting out I completely advocate bypassing the lot - you can write games without it and learning general game code paradigms is a big enough ask in general. Why complicate matters with side issues?

Hope that helps to explain where I'm coming from a little better than the ridiculous bile version from the previous poster...

(EDIT: PS. I see you linked my comment in the scene graph thread. In that case I was just getting po'd at people not attempting to answer the question, but showing off how new thinking they are instead. My previous couple of comments I thought were more than useful and constructive. But I swear someone at some point will say that integers are old thinking...)

EDIT2: I just checked out all those links and I see they're not to what I assumed they'd be, hence the above wall o' text. I've mentioned the first one, but the other three weren't openly combative at all. I advised against the methods being discussed with described insight of fails, not any latent hatred.

[Edited by - Rubicon on January 2, 2011 7:16:03 PM]
------------------------------Great Little War Game

#60 dmatter   Crossbones+   -  Reputation: 3298

Like
0Likes
Like

Posted 02 January 2011 - 12:22 PM

My opinion is that globalised and static data is an old fashioned practice that actually complicates code. Just pass stuff around as parameters and be happy.

I do enjoy a global logger from time to time however, but that's because I mostly use logging as just another debugging tool - so I don't want to side-track from debugging a problem just to go about engineering the access to a logger, I just want to a grab a logger instance, use it and move on. I'm perfectly willing to accept that I may have to go and pull those logging statements out later; but I find that to be both less time consuming and simpler compared to having engineered the logger in properly to begin with.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS