I would have thought that having a specific day for everyone to change their passwords would be more of a security risk. Surely the chance of any given password being being intercepted and / or hacked is higher if the probability of any given data transfer being a password is above average?

It also needs

AsIf unmeetable-condition
a code block which can never execute
End AsIf

kmoorevs wrote:

My first computer book ever was call "Sad Macs, Bombs, and Other Disasters". I had inherited a powermac 6100 with system 7.5. I really enjoyed all the bomb icons complete with an error number...how informative!

My favourite error was a pre-OS X Mac bomb-type message "An unexpected error has occurred because an error has occurred". Genius :)

I'd have to put my hand up and say that I've used variable names that were unintelligible to others (although mine were Star Wars references), and have probably used some esoteric (or just plain odd) structures and constructs, too. Ii you want a programming language based on a truly annoying modern abomination, though... LOLcode

It's a long time since I've used "proper" C or C++, but in C#, it won't even compile as the label is out of scope of the goto :)

I don't code in VB, so I could be well off the mark here, but isn't that GoTo also going to take you to a point where your next statment is "End If", without having actually executed the corresponding "If"? Couldn't that have "interesting" effects?

We do what we must because we can For the good of all of us (Except the ones who are dead) -- or -- The opening bars / scream of Immigrant Song :)

1. The code I work in every day still makes frequent use of GOSUB. There's even a few GOTOs lying around (which always annoy me when I see them) 2) A what? :) 3) PEEK & POKE - how else were we supposed to complete games on the old 8-bit home systems without POKEing in a cheat? :) 4) I think I installed Windows 95 from floppy disk once... I saw "Insert next disk into Drive A:" a lot just doing that...

Johnny J. wrote:

I have a task for you: Can anyone give me ONE example where layered code has proved to be a major advantage? I'm not talking about hypothetics like "Oh, what if we have to change to another type of database?" crap, because that is never going to happen in 99.9% of systems. Give me an example where someone has actually leaned back at a meeting and calmly said: "THANK GOD that we broke all the foobar code out in a separate foobar layer!" I challenge you - you can't.

Multi-platform support. We have an application that needs to run on Windows XP machines and Windows Mobile 5.0-6.5 devices. The core functionality on each needs to be as close to "the same" as possible within the platform limitations, but they each need platform-suitable UIs. We built a core library that compiles to each platform, and a data object library also for both platforms separate to the core (so we can use the data model in other applications), and just drop a relevant UI on top of the methods and events exposed by the core.

if(a>b)
{
print "b is less than or equal to a"
print "it means a is greater than b"
}
else
{
print "a is either either equal to or less than b"
}

With the exception of single-statement getters/setters, in which case

public int SomeProperty
{
get{return somePropertyValue;}
set
{
if (value != somePropertyValue)
{
someProperty = value;
// raise value changed event
}
}
}

I like that putting the open brace under the function / operation name makes it easy to spot where braces match up, but think it looks clunky when you only have a single line in a getter / setter.

- Project/bin/ which contains your builds

What is the general / advised approach when developing reusable components for later inclusion via SVN externals? Currently we have, e.g. Component x - reusable component Application 1 - application that uses component x Application 2 - application that uses component x In order to get applications 1 & 2 to use component x, we include the bin\* directories in SVN and refer to them in the applications as SVN externals pointing at the bin directories. I'm guessing from the "don't include bin" suggestion that there's a better way of doing this - any suggestions? Bearing in mind that we don't want the applications to recompile the component each time.