~ubuntu-branches/ubuntu/intrepid/perl-doc-html/intrepid

if you must. You should also always run under <code class="inline"><a class="l_k" href="functions/use.html">use</a> <a class="l_w" href="strict.html">strict</a></code>

if you must. You should also always run under <code class="inline"><a class="l_k" href="functions/use.html">use</a> strict</code>

or know the

reason why not. The <code class="inline"><a class="l_k" href="functions/use.html">use</a> <a class="l_w" href="sigtrap.html">sigtrap</a></code>

and even <code class="inline"><a class="l_k" href="functions/use.html">use</a> <a class="l_w" href="diagnostics.html">diagnostics</a></code>

100

reason why not. The <code class="inline"><a class="l_k" href="functions/use.html">use</a> sigtrap</code>

101

and even <code class="inline"><a class="l_k" href="functions/use.html">use</a> diagnostics</code>

102

pragmas

100

103

may also prove useful.

101

104

Regarding aesthetics of code lay out, about the only thing Larry

163

166

you SHOULD do it that way. Perl is designed to give you several

164

167

ways to do anything, so consider picking the most readable one. For

165

168

instance

166

169

167

170

is better than

168

<pre class="verbatim"> <a class="l_k" href="functions/die.html">die</a> "Can't open $foo: $!" unless <a class="l_k" href="functions/open.html">open</a>(FOO,$foo);</pre>

171

<pre class="verbatim"> <a class="l_k" href="functions/die.html">die</a> "Can't open $foo: $!" unless <a class="l_k" href="functions/open.html">open</a>(FOO,$foo);</pre>

169

172

because the second way hides the main point of the statement in a

170

173

modifier. On the other hand

171

174

<pre class="verbatim"> <a class="l_k" href="functions/print.html">print</a> "Starting analysis\n" if $verbose;</pre>

192

195

the middle. Just "outdent" it a little to make it more visible:

193

196

<pre class="verbatim"> LINE:

194

197

for (;;) {

195

statements;

198

statements;

196

199

<a class="l_k" href="functions/last.html">last</a> LINE if $foo;

197

200

<a class="l_k" href="functions/next.html">next</a> LINE if /^#/;

198

statements;

201

statements;

199

202

}</pre>

200

203

</li>

201

204

<li>

216

219

you know what version or patchlevel a particular feature was

217

220

implemented, you can test <code class="inline">$]</code>

218

221

(<code class="inline">$PERL_VERSION</code>

219

in <code class="inline"><a class="l_w" href="English.html">English</a></code>) to see if it

220

will be there. The <code class="inline"><a class="l_w" href="Config.html">Config</a></code> module will also let you interrogate values

222

in <code class="inline">English</code>

223

) to see if it

224

will be there. The <code class="inline">Config</code>

225

module will also let you interrogate values

221

226

determined by the Configure program when Perl was installed.

222

227

</li>

223

228

<li>

232

237

than <code class="inline">$VarNamesLikeThis</code>

233

238

, especially for

234

239

non-native speakers of English. It's also a simple rule that works

235

consistently with <code class="inline">VAR_NAMES_LIKE_THIS</code>

240

consistently with <code class="inline">VAR_NAMES_LIKE_THIS</code>

236

241

.

237

242

Package names are sometimes an exception to this rule. Perl informally

238

reserves lowercase module names for "pragma" modules like <code class="inline"><a class="l_w" href="integer.html">integer</a></code> and

239

<code class="inline"><a class="l_w" href="strict.html">strict</a></code>. Other modules should begin with a capital letter and use mixed

243

reserves lowercase module names for "pragma" modules like <code class="inline">integer</code>

244

and

245

<code class="inline">strict</code>

246

. Other modules should begin with a capital letter and use mixed

240

247

case, but probably without underscores due to limitations in primitive

241

248

file systems' representations of module names as files that must fit into a

242

249

few sparse bytes.

281

288

</li>

282

289

<li>

283

290

Always check the return codes of system calls. Good error messages should

284

go to <code class="inline">STDERR</code>

291

go to <code class="inline">STDERR</code>

285

292

, include which program caused the problem, what the failed

286

293

system call and arguments were, and (VERY IMPORTANT) should contain the

287

294

standard system error message for what went wrong. Here's a simple but

288

295

sufficient example:

289

<pre class="verbatim"> <a class="l_k" href="functions/opendir.html">opendir</a>(D, $dir) or <a class="l_k" href="functions/die.html">die</a> "can't opendir $dir: $!";</pre>

296

<pre class="verbatim"> <a class="l_k" href="functions/opendir.html">opendir</a>(D, $dir) or <a class="l_k" href="functions/die.html">die</a> "can't opendir $dir: $!";</pre>

290

297

</li>

291

298

<li>

292

299

Line up your transliterations when it makes sense:

297

304

Think about reusability. Why waste brainpower on a one-shot when you

298

305

might want to do something like it again? Consider generalizing your

299

306

code. Consider writing a module or object class. Consider making your

300

code run cleanly with <code class="inline"><a class="l_k" href="functions/use.html">use</a> <a class="l_w" href="strict.html">strict</a></code>

301

and <code class="inline"><a class="l_k" href="functions/use.html">use</a> <a class="l_w" href="warnings.html">warnings</a></code>

307

code run cleanly with <code class="inline"><a class="l_k" href="functions/use.html">use</a> strict</code>

308

and <code class="inline"><a class="l_k" href="functions/use.html">use</a> warnings</code>

302

309

(or -w) in

303

310

effect. Consider giving away your code. Consider changing your whole

304

311

world view. Consider... oh, never mind.

308

315

are commonly expected conventions:

309

316

<ul>

310

317

<li>

311

use <code class="inline">C<></code>

318

use <code class="inline">C<></code>

312

319

for function, variable and module names (and more

313

320

generally anything that can be considered part of code, like filehandles

314

321

or specific values). Note that function names are considered more readable

316

323

.

317

324

</li>

318

325

<li>

319

use <code class="inline"><a class="l_w" href="B.html">B</a><></code>

326

use <code class="inline">B<></code>

320

327

for commands names like cat or grep.

321

328

</li>

322

329

<li>

323

use <code class="inline">F<></code>

324

or <code class="inline">C<></code>

325

for file names. <code class="inline">F<></code>

330

use <code class="inline">F<></code>

331

or <code class="inline">C<></code>

332

for file names. <code class="inline">F<></code>

326

333

should

327

334

be the only Pod code for file names, but as most Pod formatters render it

328

335

as italic, Unix and Windows paths with their slashes and backslashes may

329

be less readable, and better rendered with <code class="inline">C<></code>

336

be less readable, and better rendered with <code class="inline">C<></code>

330

337

.

331

338

</li>

332

339

</ul>

355

362

356

363

</form>

357

364

365

358

366

<h2>Labels:</h2>

359

367

360

368

Older »