one liners considered good?

On a regular basis on the powershell team blog, a "one liner" is published.
It is usually does something quite impressive, cool, and awe-inspiring. And,
it is usually unreadable at first glance.

Any time I'm working with code, whether it's vbscript, vb.net, c#, SQL, etc,
one primary goal is readability / maintainability. If the code does amazing
things, but I can't read it 6 months later or figure out how to make
changes: it's bad code.

So why do we celebrate confusing one liners in PowerShell when a confusing
one liner in most other languages is criticized?

Along those lines, in any other language, I could create a function that
calls a built in function. For example:

public function l(s as string) as string
return len(s)
end function

I could then use the "l" function, instead of len. This is usually called
obfuscation. It makes the code more difficult to read for other developers
and provides no benefits. Of course, the developer calling the custom
function saves 2 keystrokes, but saving keystrokes at the cost of
readability is considered an amateur mistake.

In PowerShell, renaming built-in functions is called creating an alias and
is touted as an advantage.

Why?

Mike G.

I think the idea of one liners is showing the amazing power of Powershell...
not to promote that as a general practice.

I personally don't like them because they are normally convoluted and
require as much troubleshooting as a full fledge script.

One liners make sense for day to day task you do, but not for complex task.

"Mike G." <m4053946_noSpam_@xxxxxx> wrote in message
news:ujTyG3HAIHA.5160@xxxxxx

Hello Mike G.,
Mike - I think I can answer this

The main use of powershell is within the console, entering commands by typing,
and getting immediate results.

One liners and aliases are a LOT easier to type than multiple lines with
long commands, so in the console, "one liner’s� and aliases are considered
a "good thing"

Since I am creating applications that run powershell commands, and my code
is (fairly) static, I use the whole command, and one command per line. -
As you say, it's easier to read.

Karl

On Sep 26, 4:42 pm, "Mike G." <m4053946_noSp...@xxxxxx> wrote: Heck yeah they are! It's all about the console. These other
languages (generally speaking) don't have to deal with the dichotomy
of a scipting host that's also an interactive console. Powershell
handles it very well by giving us these shortcuts. When I'm writing
full-fledged scripts, I write things longhand or let my IDE do the
auto-complete to get the same effect.

All the best practices you stated above are still in effect for
PowerShell.



--
Blog: http://halr9000.com
Webmaster, Psi (http://psi-im.org)
Co-host, PowerScripting Podcast (http://powerscripting.net)

"Karl Mitschke" <kmitschke@xxxxxx> wrote in message
news:7063857f9ab68c9ce64edbcac9e@xxxxxx +1 : my wrists really appreciate these one-liners
and +1

--
Keith

I don't like the over aliased one liners that we keep seeing & tab completion
while not perfect does take a way a lot of the typing
--
Richard Siddaway
Please note that all scripts are supplied "as is" and with no warranty
Blog: http://richardsiddaway.spaces.live.com/
PowerShell User Group: http://www.get-psuguk.org.uk


"Hal Rottenberg" wrote:

Hello RichS,

I'd forgotten about tab completion in the console! That rocks, usually!

Karl

As an aside, with some of the new stuff coming in V2, we should be able to
offer both better tab completion (for everyone, not just the in default
host) as well as tools for analyzing and canonicalizing scripts. This will
allow you to write your scripts the way you want and then convert them into
canonical form for redistribution. We're also working on a style guide/best
practise document that (hopefully) we'll release for review soon...

-bruce
--
Bruce Payette [MSFT]
Windows PowerShell Technical Lead
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no rights.

Visit the Windows PowerShell Team blog at:
http://blogs.msdn.com/PowerShell
Visit the Windows PowerShell ScriptCenter at:
http://www.microsoft.com/technet/scr.../hubs/msh.mspx
My Book: http://manning.com/powershell

"Karl Mitschke" <kmitschke@xxxxxx> wrote in message
news:7063857f9d478c9cef3410f97ec@xxxxxx

"Bruce Payette [MSFT]" <brucepay@xxxxxx> wrote in message
news:eScHMDaAIHA.4712@xxxxxx

The best practice guide sounds like a good idea.

I'm not normally a fan of these, but in the case of Powershell there often
seems to be a large number of ways that you could achieve exactly the same
end, and it's not always obvious which is the best way to achieve it.

While freedom is good thing (no-one likes to be over-prescribed to), it 's
also good to have guidance as to what you guys at MS would consider the best
usage of the different technological areas

eg when it would be considered best practice to

1. Put code into the main body of the script
2. Put code into a function
3. Put code into a custom cmdlet
4. 'Dot source' an external script
5. Run an external .ps1 script
6. Use 'inline VB / C#'
7. Create a custom .net class
8. Script existing /downloadable COM objects or create one's own
9. Run external executables, either existing or one's own
etc

This is an area that I currently struggle with, so anything in your document
that helps with this would certainly be of value.

--
Jon

I use PowerShell commands in MsBuild files to get extended functionality. In
an MsBuild file, I like one-liners, preferrable short one-liners. That gives
a better overview of the MsBuild file. A short one-liner accompanied with a
good comment could be considered as an idiom.

"Mike G." wrote: