This is how i code my own project and i don't feel good about it

That darn inflation. Back in my day software could run just fine on only several thousand lines of code.

 

It gets dicey and really pedantic if I start mentioning every place where code us reused. Methods are code reuse, for example. Classes and objects are code reuse to the nth degree.

I feel like I'm going to tinker with a console window and learn all those old timey algorithms just for fun. But it won't make me smart to know them... that's where I have issue. Being a whiz with cs doesn't mean you're super smart, any more than knowing anything else. It's logic and math, in the end, isn't it? Follow the instructions... point a goes to point b... search, sort... honestly seems like an abacus compared to a calculator to think about some of those old algorithms.

 

I'm still not sure I'm following the conversation But I think I agree.. Hopefully I've clarified what I meant anyway.

And I definitely agree with the algorithm thing (sorry if that old half-finished comment crept in there when it wasn't meant to - I've edited it out now).
I definitely think programmers SHOULD know basic sorting algorithms etc (or at the very least, determine when you might need to apply them) and I'd be worried about hiring someone who didn't - But I'd much rather hire a programmer who has experience solving real-world issues.

So I agree - it's a poor metric to use to measure a programmers intelligence/productivity/experience alone, but I don't have any problems with someone using them in an interview, as long as it is only part of the interview (hopefully that makes sense?).

A lot of algorithms are common sense. For example, binary search - it's the same algorithm most people would have applied to a higher/lower number-guessing game as a kid.

 

I think it's a fair question to ask. It discriminates against people who haven't had any background in academic cs a little bit, but at the same time... algorithms are language independent. It depends on the situation. I don't think I've ever used a comb sort since the 10th grade, though.

 

I love that we have 2 pages of comments, with everyone chiming in their answers... Not a single person asked for details on the guys projects are, or even generally what kinds of things he might be splitting out.

 

*And one more comment.

I think at this point certain thread posts are just jumping off points for a discussion.

 

Well, he/she did ask how we felt about it..

 

My point is that almost all programmers I've ever known (even very good ones) tend to be extremely dogmatic. You even get to the point where people are like:

"If you don't put a curly brace on it's own line you're terrible!"

Programming is kind of weird. We generally want to think of programming as not subjective because it's mathy and logicalie. But the reality is that 'good code' and 'bad code' can really be incredibly subjective.

One of the best examples is probably NGUI. This is a pretty amazing API, it's been used by thousands of Unity developers. I look at NGUI's codebase and have such strong mixed feelings about it. The code is smart, it's efficient and it's internally very consistent. It's also extremely unusual and deeply idiomatic. It's a nightmare to make changes to any of it. Like, holy S*** is it horrible to change.

Is NGUI good code or bad code? It's really an interesting example of small, component based design, it also shows some of the difficulty in extending that design out and how unbelievably horrible that design can become to manage once more and more complexity starts to seep into the overall requirements.

The overall design of the NGUI system is incredibly elegant. How the pieces work together is just beautiful design at a very high level. There's a reason Unity decided to hire the guy to work on ugui. I can also immediately understand why the relationship between him and unity ended before ugui was released. You can really tell a huge amount about a persons personality by their code, and NGUI has a lot of personality.

What if you joined the NGUI team before it was released and before it had become such a successful product? If just about any programmer who has commented in this thread had joined that project half way in - they'd look at that code base and just be like "holy crap, this is a disaster, i need to rewrite all of it".

Do you think that if you did that, and you wrote ngui to be more to your stylistic preferences - do you think it'd be a better product?

 

That's the real reason compilers exist. At the end of the day, most good code and bad code will produce nearly identical binaries. It's what lets us agree to disagree. If I wanna write my entire program inside main and use several hundred branches then that's what I'm going to do!

Any thoughts on min.css and min.js? Sometimes people don't care about readability for a library/api they're referencing

 

Many large employers want to discriminate against people without an academic background. Much of my degree is irrelevant to my job. My industry would still not employ me without it.

There are still plenty of opinions about degree versus self taught in game development. But if the employer wants a CS degree there is not much you can do except get the degree.

 

I know what you mean - it's almost as though dogmatism is a necessary trait for a programmer to have. That's pretty much what my "did ask how we felt" comment was referring to - asking a programmer how he/she feels about code is always going to stir up big arguments
And it's hard not to care about something that you put a lot of pride/effort into.

As for your NGUI question, I think that about all code. My own code, other people's code - code is never perfect (at least I've never seen any). But there is a difference between needing to rewrite and wanting to rewrite. I might WANT to rewrite if I don't like the structure/style of someone elses code, but I won't touch it unless I have good reason to.

It's the reason we have thousands of open source libraries doing the exact same thing. And I don't think that's a bad thing

 

This may be true early in a project. However, as the project grows in size and complexity, clean code is critical for managing that size and complexity.

 

At least it's not AngularJS. A framework that encourages you to declare objects, assign new values to objects, set properties on objects and embed anonymous functions in a single line of code... but also encourages you to use newlines to make it semi readable.

These blocks are usually closed off by this:

Code (JavaScript):

1. )]})};

It makes me long for the end of creation.

 

Certainly not with that attitude.

 

Luckily we're in unity. If a part of your project starts to act strangle, write another script to disable that first script when things go strange and run separate code.

That's how I handled "teamwork" in school.

 

You'd disable your teammates?

 

That's certainly one way to handle design disputes in a team with no strong lead.

 

It's not the attitude of the person applying that matters, but the attitude of the company hiring. Unfortunately, there are many companies which use a checkbox approach to hiring. Don't have the checkbox? You're not hired. In some cases, the computer eliminates you before you a human ever sees your resume because you failed to hit some listed requirement. Attitude doesn't mean a thing when the system says "you're not qualified" and so you cannot even be considered.

I remember way back in the day someone complaining because HR terminated the interview with them because it turned out the programmer's multiple years of experience was in BASIC and not Visual BASIC. I have also see folks cite job listings what want X amount of experience with some software that has been out for fewer than X years.

Stupid? Yes. But real world companies do unfortunately work that way.



In answer to the OP: I like to break my systems down into multiple control units that handle different operations. I might have a GameMaster which holds score and certain game states, a PlayerMovement which handles moving the player around, and an AIController for the NPCs. I try to stick to the idea of single-purpose where possible.

When I go to create a new project, I sit down with paper and pen or with a word processor and I start breaking down the systems I will need. This helps me create something between an outline and a table of contents type document and really helps me to see what modules I am going to need in the program. It may not be a typical approach for games; games being only my hobby and my programming experience primarily being elsewhere.

 

Personally when I code, I make scripts that are as generic as possible at first, doing something super simple, like tuning an object off when a player enters a trigger. I then make more specific scripts that rely on the generic ones, for example a script that detects whether that game object is on or off and does something depending. I can make many of these small scripts and suddenly I have a reliable easy system to control multiple tasks from the generic script. This gets especially useful if you have a variety of enemies in your game, and yoiu need them all to attack differently, but they all need the same health and damage scripts.

 

I've never worked for a company like that, I probably never will. In my last job I melted metal with blowtorches and smashed things with sledgehammers. I know about the resume filters. You're not only not hired, you're not displayed. It basically breaks you down into areas of experience and the number of years you've been doing it and presents the staff with various filter options. Ultimately, this is what you are to those companies:

0 YEARS EXPERIENCE WITH A
1 YEARS EXPERIENCE WITH B
3 YEARS EXPERIENCE WITH C

Then if you match their requirements, they bring you in and make you take the impossible quiz while several people watch.

In fairness, those companies generally get 600 people applying for the same job whenever they post an opening. The vast majority of which probably can't do the job, anyway... and then anyone really talented will find a better opportunity and leave as soon as they get an offer.

When you look at the whole picture, is it really stupid?

Personal attitude matters, infinitely more than anything else can possibly matter. There are opportunities in this world, but you're not going to find them looking where everybody else has already looked for them.

 

Yes. One guy was developing the character controller but had issues with slopes, so I wrote a slope handler script that disabled the main controller when ever the character ran into a slope then ran my code. When the character exited a slope, it switched back to the main controller.

It's how I became the over aggressive lead on my team.