Is this Kosher ?

Anon

<?
include $ThePath . 'my_funcs_folder/fncXYZ.php';
?>

I set $ThePath to point to different locations, depending upon which host I am on, local or remote. If it's local (127.0.0.1) it gets set one way, and if not, another way.

This works, but I'm not sure if it's good coding style. I am trying to avoid having a big "if . . . else" statement for including files.

van__

If it's got pork it's never Kosher.

And I place calling functions without the ()'s about as porky as using ASP tags
and other alternate syntax crap that they put in just so kids in middle school could feel like /\/\4|] |-|4><0|^ |]00|]$
just like in Hackers (haha) and the Matrix.

Anon

if it works its fine, I do a similar setup for work that I do on win & upload to *NIX, I also love not using ()'s if and where possible, why anyone would want to type more than they have to escapes me ? l33t or not, wise or otherwise

Anon

Hey, great movie!

But would not the addition of those "()" be more pork?

Of course, if your "()" are approved by the Rabbi, then you can make your case :-)

Anon

VB6 takes those "()" out, even if you type them in. Guess I had a little Freudian VB slip there!

I just wanted to make sure that what I was doing with the path thingy was not going to cause a major debugging headache down the road, as us programmers are sometimes to clever by 1/2.

Anon

van__

Don't know about you, but I like nice easy to read code.

I don't really care if some funky syntax works.
What I do care about is efficient code that is well formed and portable between developers.

What do I mean about portability?

I mean, I have 5 or 6 subcontractors working
under me at any given point in time.
I have object libraries that need to be maintained and updated as well as new objects that get written for each new project.

I want my 60,000+ lines of code to be consistant and understandable by everyone involved.

I don't know your background,
but I work a lot of projects and also get brought in by corporations to provide guidance. And a lot of that guidance is how to write and structure large codebases since one of my fortes happens to be software architecture.

I have some real tough policies that I enforce and crap like ASP tags and alternative syntax does not make it with me.

Why?
Well when you have 4 or 5 projects going on at once in multiple software languages with teams that share workers from other teams, you want code that can be picked up and read fluently by any of your developers and yourself at anytime.

But, hey...
Don't listen to me.
Go write your own way and see how groovey you can make it.

You'll probably never work in the capacity I work in anyway, so it probably wont matter much.

But if you ever do get there...
you might just appreciate much of what I just said.

Anon

rule: the more like c a given syntax looks the greater the number of people who will be able to read it easily.

Anon

As both a technical writer and programmer (with almost 22 years of experience) it should not surprise you that I agree with 99 percent of what you say. I absolutely hate going thru someone else's poorly documented, crap code. I've worked on a lot of projects where the programmer quit and left a mess, and I had to go in and clean it up.

But that's not the way I work, bud. I try to document as I go, NOT as an after thought like so many do (or end up never doing).

Hey, the porky thing was a JOKE, OK??? Don't let the stress of that job get to you so much.

So lighten up a bit, will ya! You might be a little more fun to work around if you had a sense of humor. Besides, 100 years from now, nobody will give a damn what we have said here :-)