Again, that is where the simplicity/Arch  principle comes in. Things happen when and where approriate; making sense of it all. There are 2  primary cases:<br><br>1) Traditional reason for variables - shorter   alternatives to longer strings<br>
<br>2) Portability/flexibility - other programmers  are able to manipulate your code easily (for PKGBUILDS; those editing it)<br><br>So if the script doesn&#39;t have any  content relating to (1) or (2) then yet another variable is indeed pointless. We should avoid them unless the benefit is practically significant.<br>
<br>Say, for instance, a short PKGBUILD where the     source archive&#39;s $pkgver != real $pkgver. You are going to submit it to [unsupported] where the AUR web interface cannot resolve custom variables, and the source  archive&#39;s name has an underscore. You create _pkgver as the new one, and you use it in the source array as ${pkgname}_${_pkgver}, which could do with some cosmetic surgery. Then&nbsp;it&#39;d&nbsp;be up to you to decide whether this new variable, or having a clean look on the web interface, is more beneficial/&quot;important&quot;.<br>
<br>Since bumping pkgver will not change the source, introducing _pkgver makes it easy to update. At the&nbsp;same time, though,  if one is editing the PKGBUILD the source array isn&#39;t that many lines down and thus, is as easy as changing the value of a variable. It&#39;s a matter of weighing priorities; takes a few seconds before clicking on &quot;submit&quot;. In [community] (ABS), this isn&#39;t a problem but then - as a TU - you should be able to do the weighing just fine. I don&#39;t know if I&#39;m guilty&nbsp;as an [unsupported]  user but I sure hope not =P <br>