Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>1) As far as which ones I use often:</p> <ul> <li><p>$! is quintessential for IO error handling</p></li> <li><p>$@ for eval error handling when calling mis-designed libraries (like database ones) whose coders weren't considerate enough to code in decent error handling other than "die"</p></li> <li><p>$_ for map/grep blocks, although I 100% agree with a poster above that using it for regular code is not a good practice.</p></li> <li><p>$| for flushing buffers </p></li> </ul> <p>2) As far as using punctuation vs. English names, I'll pick on Marc Bollinger's reply above although the same rebuttal goes for anyone arguing that there's no benefit to using English names.</p> <blockquote> <p>"if you're using Perl, you're obviously not choosing it for neophyte readability" </p> </blockquote> <p>Marc, I find that is not always (or rather almost never) true. Then again, 99% of my Perl experience is writing production Perl code for large companies, 90% of it full fledged applications instead of 10-line hack scripts, so my analysis may not apply in other domains. The reasons such thinking as Marc's is wrong are:</p> <ul> <li><p>Just because I'm a Perl non-neophyte (to put it mildly), some noob analyst hired a year ago - or an outsourced "genius" - is probably not. You may not want to confuse them any more than they already are. "If code was hard to write, it should be hard to read" is not exactly high on the list of good attitudes of professional developers, in any language.</p></li> <li><p>When I'm up at 2am, half-asleep and troubleshooting a production problem, I <strong>really</strong> do not want to depend on the ability of my already-nearly-blind eyes to distinguish between $! and $|. Especially in a code written by before mentioned "genius" who may not have known which one of them to use and switched them around.</p></li> <li><p>When I'm reading a code left unfinished by a guy who was <em>cough</em> "restructured" <em>cough</em> out of the company a year ago, I'd rather concentrate on intricacies of screwy logic than readability of the punctuation soup.</p></li> </ul>
    singulars
    1. This table or related slice is empty.
    1. POWhat's good practice for Perl special variables?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USscobi
    1. USDVK
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POWhat's good practice for Perl special variables?
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. This table or related slice is empty.
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload