start page | rating of books | rating of authors | reviews | copyrights

Book HomeMastering Perl/TkSearch this book

1.5. Unsolicited Advice

Before we end this chapter, and you become engrossed in the details of Perl/Tk, we'd like to give you some suggestions on programming style and window design. Bear with us, this won't take long and might save you a lot of time in the future.

1.5.1. Programming Style

The code in a Perl/Tk script can get quite cumbersome and clunky because of all the option/value pairs used to define and configure each widget. There are several ways to format the code to deal with readability (and in some cases, "edit-ability"). Most just involve adding extra spaces or tabs to line up different portions of code. Once you get used to seeing the code, it won't seem quite so mysterious and unwieldy.

One coding style places each option/value pair on a separate line:

$bttn = $parent->Button(-text => "my text",
                        -command => sub { exit }, 
                        -width => 10, 
                        -height => 10);

With this style, it is extremely obvious what the pairs are and what value is associated with which option. (You could also go to the extreme of aligning each => to make nice columns, depending on how much time you have to press the spacebar.) Some people like to start the option/value pairs on the next line and put the ending ); on its own separate line, after the last option/value pair, which retains the comma for formatting ease:

$bttn = $parent->Button(
   -text => "Exit", 
   -command => sub { exit }, 
   -width => 10, 
   -height => 10,
);

This makes the code easier to edit; an option/value pair can be added or deleted on each line without having to mess with parentheses, semicolons, or commas. It also keeps the next lines closer to the left side of the page, so if you have several indentation levels, you don't end up with code quite so deeply nested to the right.

In either case, Emacs users may find the functionality of cperl-mode.el handy. This is an Emacs initialization file that adds color highlighting and special formatting that makes editing Perl code more efficient. You can find the file in the standard Perl distribution, in the perl-5.6.0/emacs directory.

Sometimes if there are only one or two option/value pairs, it makes sense to leave them all on the same line and conserve a little bit of space:

$bttn = $parent->Button(-text => "my text", -command => sub { exit });

You'll eventually come up with a style that works for the way you read and edit code. Whichever way you choose, try to be consistent throughout your scripts in case someone else takes over the maintenance of your code (it might even be you, a year or more down the road).

1.5.2. Naming Conventions for Widget Types

Sometimes your programs run away from you, getting so large and unwieldy that it becomes hard to remember what a particular variable was pointing to. If there are over 10 Buttons in a program, we would be hard-pressed to figure out which Button was $button3 without digging through a bunch of code.

So we've established a naming convention for our code. You don't need to use our convention, but it'll hopefully inspire you to come up with your own. Otherwise, we hope you have a really good memory.

For Buttons, you might use _b, _bttn, or Button as a type of qualifier to the variable name. For instance, you could name the Button in the Hello World example $done_b, $done_bttn,or$doneButton.

The topmost widget in an application's widget hierarchy is the MainWindow. Throughout this book, we use the variable $mw to represent this widget. You will see other programs use $main, $top, or $mainwindow as well.

Table 1-1 lists widget types and suggested naming conventions for them. Replace "blah" with a sensible description of the widget's purpose (e.g., exit). If you use this convention, you'll always know what type of widget you're working with.

Table 1-1. Naming conventions by widget type

Widget type

Suggested name

Examples

Button

$blah_b, $blah_bttn, or $blahButton

$exit_b, $apply_b, $newButton

Canvas

$blah_canvas or $blahCanvas

$main_canvas, $tinyCanvas

Checkbutton

$blah_cb or $blahCheckbutton

$uppercase_cb, $lowercaseCheckbutton

Entry

$blah_e or $blahEntry

$name_e, $addressEntry

Frame

$blah_f or $blahFrame

$main_f, $left_f, $canvasFrame

Label

$blah_l or $blahLabel

$name_l, $addressLabel

Listbox

$blah_lb or $blahListbox

$teams_lb, $teamsListbox

Menu

$blah_m or $blahMenu

$file_m, $edit_m, $helpMenu

Radiobutton

$blah_rb or $blahRadiobutton

$blue_rb, $grey_rb, $redRadiobutton

Scale

$blah_scale or $blahScale

$age_scale, $incomeScale

Scrollbar

$blah_scroll, $blah_sbar, or $blahScroll

$x_scroll, $yScroll

Text

$blah_t or $blahText

$file_text, $commentText

Toplevel

$blah_w or $blahWindow

$main_w, $fileopenWindow

1.5.3. Designing Your Windows

Before you decide what events to handle, it is worthwhile to spend some time sketching out a few windows on paper and deciding what should happen (from the user's perspective) when you click a button or invoke a menu item.

A GUI often makes the application look much more polished and purposeful than a command-line interface does, but it's easy to go overboard with a GUI and end up with something ugly, clunky, and impossible to navigate. So here are some things to consider when deciding how the GUI should look:



Library Navigation Links

Copyright © 2002 O'Reilly & Associates. All rights reserved.