[Rhymer]

Hey, y'all! I've been gone a while and thought some of the gurus of coding can offer any secret tips that you use that saves time or makes remembering variables easier. Sorry if mods want to move this to cubical.

I like to start all arrays at 1 and reserve the 0'th element for temp holding.
I like to use fairly long names for variables so they are more descriptive than short names since it is pretty easy to cut/paste them into a procedure copied for ,say, read/write operations.
Do you have your own system of routines for boiler plating?
What is your favorite sort method? If the data is already sorted and the record count isn't too high (<1000) then bubble is adequate otherwise I use Jsort which is a variant of shell.

I am working an a small program to time TV vs commercial durations. Since it has been a while (I'm a bit out of shape coding wise) I find dealing with date/time kinda onerous. Maybe someday someone can develop a base 60 language to handle time.

Anyways, I miss you guys and gals and I hope to relearn what I've forgotten.

Rhymer

[modi123_1]

Sure.. to the software dev area we go!


I tend to prefix my variables for their types and GUI controls all get "ux" prefix so I know where to find them and that they are GUI.

[DarenR]

I code my variables so I know what they are for, like

name_cb= name combo box
name_txt = name text box
name_lst = name list
name_lbl = name label

and so on

This post has been edited by DarenR: 30 August 2012 - 11:57 AM

[sepp2k]

Rhymer, on 30 August 2012 - 08:05 PM, said:

What is your favorite sort method?

The one used by the standard library of the language I'm programming in.

[Rhymer]

@DarenR I suppose you mean the letters 'name' are a variable. I usually do the opposite as in cbo_name, cmd_name, etc (without the underscores).

@sepp2k So you rely on an internal language supplied sort? Wow, that is really handy. Do they say which type of sort routine it is or is it transparent? Another VB website has a very knowledgeable sort routine maven and it would be a merri time if you could locate the thread.

It seems to me there are two types of sort requirements: those of a rather small set and those that are quite large. Even with multiple fields on small set (<1000 records), if they are already sorted, which is usually the case when adding one at a time and sorted each time, the lowly bubble sort is adequate and the easiest to code IMHO. If, however, you exceed 10,000+ records then another method is recommended especially if the data is not sorted.

@modi GUI controls like chkbox, cmd, opt, lbl, txt? Prefixing them with 'ux' seems counter-intuitive.

[modi123_1]

Quote

@modi GUI controls like chkbox, cmd, opt, lbl, txt? Prefixing them with 'ux' seems counter-intuitive.

Yes. Why would that be counter intuitive?

[jon.kiparsky]

Re: sorting, I don't use VB, so I can't say there, but languages I use all have sorts written. I could write any of the standard sorts if I had to - I'd probably pull down my copy of Sedgewick to crib from - but fortunately I don't ever have to think about that.
Which sort to use? Do I care? What I care about is getting the program written.

As for variable naming, I'm absolutely allergic to hungarian-type naming schemes. Generally, I keep my variables local to minimize namespace conflicts, which cuts out a lot of the need for that. I keep my methods short, so there's not a lot of opportunity to forget the type of any one variable. And if I'm dealing with multiple GUI elements, I'm keeping them in a map or other collection for easy bulk access, so they don't get names to begin with.

So I end up using variable names that communicate intent.

For example, from a going project:

   /**
    *   Load the chosen set of Player objects for the selected game. Player
    *   objects are selected by choosing an appropriate ClassFilter, from the list
    *   of Players mapped to this Game when listGames() is run. 
    *   @param chosenGame the Class for the game we wish to play
    *   @param filter the ClassFilter passing only the classes we need to load
    */
    public ArrayList<Player> loadPlayers (Class chosenGame, ClassFilter filter)
                throws TourneyException
    {
        ArrayList<Class> classList = gamesToPlayersMap.get(chosenGame);
        ArrayList<Player> players = new ArrayList<Player>();
        for (Class c: classList)
        {
            if ( filter.filter(c))
            {
                Object o = null;
                try {
        
                    o = c.newInstance();
                }
                // error handling omitted - essentially, we log failures
            players.add ((Player) o);
            }
        }
        return players;

    }

This it part of a larger process, obviously, but it should be pretty clear what's going on here - we're getting a list of players for a particular Game, which we've prepared previously, and we're filtering out some of them and instantiating the ones we keep, and returning them in a list.
Because it's short and simple and does one thing, there's no need for prefixes, so it's easy to read. There's no secret, just common sense: keep it simple, do one thing at a time, and keep your code tidy.

[sepp2k]

Rhymer, on 30 August 2012 - 09:43 PM, said:

@sepp2k So you rely on an internal language supplied sort?

Why wouldn't I? There's very rarely a good reason to re-implement functionality that already exists in the standard library.

Quote

Do they say which type of sort routine it is or is it transparent?

I imagine that the majority of languages leave the choice of algorithm implementation defined, though particular implementations might document their choice.

In the majority of cases I don't care about which algorithm is used, so it doesn't really matter.

Quote

It seems to me there are two types of sort requirements: those of a rather small set and those that are quite large.

That's why there are hybrid algorithms that combine an algorithm which does well for small and largely sorted inputs with one that does well for large inputs. The most popular example is Timsort which combines insertion sort and merge sort.

Quote

Even with multiple fields on small set (<1000 records), if they are already sorted, which is usually the case when adding one at a time and sorted each time

If you're sorting after each insertion, you're doing it wrong. You should be using a self-sorting data structure like a search tree/tree set. Most languages' standard libraries contain such a data structure.

Quote

the lowly bubble sort is adequate and the easiest to code IMHO.

When inserting an item into an already sorted collection, insertion sort easily beats bubble sort (and, as I said, using a tree will beat either except for very small inputs). I don't think there's any scenario where bubble sort is preferable.

This post has been edited by sepp2k: 30 August 2012 - 01:19 PM

[jon.kiparsky]

sepp2k, on 30 August 2012 - 03:17 PM, said:

Why wouldn't I? There's very rarely a good reason to re-implement functionality that already exists in the standard library.

I can think of only two reasons. One, to learn how it's done. This is a good thing to do. The other, if you find a bug in the standard library. This is so rare I only mention it for completeness.
Sepp is absolutely right: there is no reason to think about writing a sort routine when you need something sorted. It's already been done.

[sepp2k]

jon.kiparsky, on 30 August 2012 - 10:23 PM, said:

I can think of only two reasons. One, to learn how it's done. This is a good thing to do. The other, if you find a bug in the standard library. This is so rare I only mention it for completeness.

I can actually think of one more: When you're using your own data structure and the standard library's sort is either not generic with regards to the used data structure (C++'s std::sort will work well with any mutable data structure that allows efficient random access, but most other language's sort-functions aren't that adaptable) or won't work well with your data structure for other reasons.

For example I once implemented a disk-based hybrid merge sort for a database that was developed at my university. Obviously general sort functions won't work well (or, in many cases, at all) for such a scenario.

That's not really a common situation though (and most certainly not one where one would consider using bubble sort).

[jon.kiparsky]

Yeah, that's not a use case that I've run into.

[Lemur]

Use monkey patching and other nasty tricks to switch the string and integer classes to ensure job security.

On a more serious note, framing is a common technique of mine. I start by writing out all the methods I need, then all the variables, and down the line so as to ensure that I don't go crazy in one method and actually have to work within standards.

I also follow the 70/30 rule, 70% of my time should be spent planning, sketching, and finding requirements to 30% of actually writing the code. I've found that there's an average of a 1:5hour ratio between planning and coding. One hour of planning can easily save 5 hours of coding.

Most of my philosophy is that I should never sit down and just write code, but I should always have a plan of attack that is thorough and concise in nature.

Oh, and I actually did do that monkeypatching bit once for my own amusement.

[Skydiver]

Off topic:

jon.kiparsky, on 30 August 2012 - 01:23 PM, said:

Sepp is absolutely right: there is no reason to think about writing a sort routine when you need something sorted. It's already been done.

Yet, many a job interview asks candidates to implement quick sort or heap sort... Why do you need to know if a candidate knows how to implement it if you don't expect them to write it when they get the job?

[Skydiver]

Back on topic:

My tip for coding is: "Consider using the Test Driven Development methodology." The effects of this three fold:

• You have a set of tests for your code right away.
  
• It reinforces Lemur's tip of doing planning and sketching, but you feel like you are making progress because you are writing test code, and double checking that the test code mimics the requirements for the project.
  
• You avoid feature creep. If you follow the TDD tenets, you'll have code that focuses on making tests succeed using "the simplest way possible".

[jon.kiparsky]

It's not a question I'd ask, at least not that way, but I can see why someone might ask it.

The idea would not be to check whether you can write a sort from scratch - if you ever needed to, you'd pull down a collection of algorithms or look it up, but you're not going to need to.
The point would be to watch you develop a piece of code, to learn something about the way you work and the way you think and the way you communicate what you're thinking about the work you're doing.
Why use sorts for this? Well, what they're algorithms that just about anyone who's been through any formal training will be familiar with, so it's a safe one to ask about. And because quick sort has some tricky steps in it, there are some opportunities for things to go wrong - how do you handle that? Do you catch your mistakes, or do you miss them? How do you deal with it when things go wrong? (if needed, the interviewer can force that question by throwing in curve balls: this isn't just them being mean, it's them doing their job!)

This certainly doesn't mean that you're going to write sort routines. It could happen, but for most the most part it makes as much sense as writing your own String class. You should be able to do it, but if you ever actually do, you'd better have a very good reason.