puppet code indentation

[Ohad Levy]

Hi All,

just before I'll consider writing a script, Does anyone has a good way to auto indent, or better fix indent for exists file?

Thanks,
Ohad

[Jean-Baptiste Quenot]

Puppet comes with a syntax file for Vim. It understands the Puppet
language, and provided you 'set autoindent' the indentation will be
good, and you can reindent with the = command on a selection.
--
Jean-Baptiste Quenot
http://jbq.caraldi.com/

[Ohad Levy]

Hi,

I'm aware of vim support for indentation, and also for setfiletype puppet in vim.
I don't know if you tried to '=' on a whole file, it doesn't really work.

What I'm looking is to have a way to standardize the way my puppet manifest looks like, since we have multiple authors each one with his own editor (tab vs spaces etc)....

Thanks,
Ohad

[jtimberman]

On Jul 20, 8:20 pm, "Ohad Levy" <ohadl...@gmail.com> wrote:
>
> What I'm looking is to have a way to standardize the way my puppet manifest
> looks like, since we have multiple authors each one with his own editor (tab
> vs spaces etc)....

There's no set standard, of course. The wiki StyleGuide page prefers 4
spaces:

http://reductivelabs.com/trac/puppet/wiki/StyleGuide

Though I didn't see specific recommendation/reference to 4 spaces,
just noticed that in the example manifests used.

I personally prefer 4 spaces, but where I work the standard is 2
spaces. It was easy enough to modify my .vimrc to accommodate.

[Daniel Pittman]

jtimberman <grump...@gmail.com> writes:
> On Jul 20, 8:20 pm, "Ohad Levy" <ohadl...@gmail.com> wrote:
>>
>> What I'm looking is to have a way to standardize the way my puppet manifest
>> looks like, since we have multiple authors each one with his own editor (tab
>> vs spaces etc)....
>
> There's no set standard, of course. The wiki StyleGuide page prefers 4
> spaces:
>
> http://reductivelabs.com/trac/puppet/wiki/StyleGuide
>
> Though I didn't see specific recommendation/reference to 4 spaces,
> just noticed that in the example manifests used.

The ruby-mode file for Emacs, supplied with puppet, prefers 2 space
indentation, for what that is worth.

Regards,
Daniel

[José González Gómez]

On 21 jul, 04:20, "Ohad Levy" <ohadl...@gmail.com> wrote:
> Hi,
>
> I'm aware of vim support for indentation, and also for setfiletype puppet in
> vim.
> I don't know if you tried to '=' on a whole file, it doesn't really work.
>
> What I'm looking is to have a way to standardize the way my puppet manifest
> looks like, since we have multiple authors each one with his own editor (tab
> vs spaces etc)....
>

I remember from my Java coding days that there were a few code
"beautifiers" that let you configure every aspect of code presentation
(not just indentation) and then reformat a whole project. Even Eclipse
introduced a long time ago a code formatter that kept your code
correctly formatted according to your coding standards, using a coding
style definition that could be installed in every developer machine.
Maybe you could take a look to some of them and try to adapt it to
puppet code (don't know if it's possible)

I don't know if people would appreciate such a thing regarding puppet,
but I think these kinds of tools are great for improving code
readability, as all the code for a project (team? company?) is always
formatted the same way and after some time you get used to it.

Best regards
Jose

[Daniel Pittman]

José González Gómez <jose.gonz...@gmail.com> writes:
> On 21 jul, 04:20, "Ohad Levy" <ohadl...@gmail.com> wrote:
>>
>> I'm aware of vim support for indentation, and also for setfiletype
>> puppet in vim. I don't know if you tried to '=' on a whole file, it
>> doesn't really work.
>>
>> What I'm looking is to have a way to standardize the way my puppet
>> manifest looks like, since we have multiple authors each one with his
>> own editor (tab vs spaces etc)....

If you forgive my saying so, this is a social problem rather than a
technical problem. Solve it by talking to your authors and getting
agreement on appropriate coding standards.

This is important, because ...

> I remember from my Java coding days that there were a few code
> "beautifiers" that let you configure every aspect of code presentation
> (not just indentation) and then reformat a whole project. Even Eclipse
> introduced a long time ago a code formatter that kept your code
> correctly formatted according to your coding standards, using a coding
> style definition that could be installed in every developer machine.
> Maybe you could take a look to some of them and try to adapt it to
> puppet code (don't know if it's possible)
>
> I don't know if people would appreciate such a thing regarding puppet,

... this technical approach is going to cause you a universe of grief.

The first reason is that when you apply the code reformatting tool you
just created a commit that rewrote (or most) of the history under your
user ID.

This means that tools like blame/annotate can't determine who was
responsible for individual parts of the code as effectively.

It also means that all your authors have a single point in time around
which they need to restructure all their outstanding work -- they have
to merge this new change in, in one big burst of effort.

> but I think these kinds of tools are great for improving code
> readability, as all the code for a project (team? company?) is always
> formatted the same way and after some time you get used to it.

This isn't as bad as what this seems to imply, though, which is running
this sort of tool on a regular basis. Ouch!

Every time you reformat code you cause extra work for the other authors,
which is not going to be appreciated.

Worse, if you don't get agreement on this beforehand imagine what your
other authors will do: because you reformatted code, they will feel
they, also, can reformat it.

So, they run the reformatter to get their own preferred style uniformly
applied across the codebase, you change it back, and it all ends up with
someone getting stabbed in a back alley.[1]

So, solve the *social* problem with social tools, not technical ones.

If you do that, and it seems *really* important -- and you can justify
the technical cost -- then use a reformatter *once* on your codebase.

Regards,
Daniel

Mostly, though, just don't do it.

Footnotes:
[1] This is probably an exaggeration, since most developers and
sysadmins are too lazy to actually stab you. ;)

[Ohad Levy]

So, solve the *social* problem with social tools, not technical ones.

If you do that, and it seems *really* important -- and you can justify
the technical cost -- then use a reformatter *once* on your codebase.

 

I agree with you fully :)
the only technical thing I could think of is to use a hook in the version control to format the file before saving.

Thanks,
Ohad

[José González Gómez]

I don't agree with you (although I agree with some of the things you
say)... comments inline

On 26 jul, 04:34, Daniel Pittman <dan...@rimspace.net> wrote:

> José González Gómez <jose.gonzalez.go...@gmail.com> writes:
>
> > On 21 jul, 04:20, "Ohad Levy" <ohadl...@gmail.com> wrote:
>
> >> I'm aware of vim support for indentation, and also for setfiletype
> >> puppet in vim.  I don't know if you tried to '=' on a whole file, it
> >> doesn't really work.
>
> >> What I'm looking is to have a way to standardize the way my puppet
> >> manifest looks like, since we have multiple authors each one with his
> >> own editor (tab vs spaces etc)....
>
> If you forgive my saying so, this is a social problem rather than a
> technical problem.  Solve it by talking to your authors and getting
> agreement on appropriate coding standards.
>

No, this is a social AND a technical problem.

First of all, I wasn't talking about a group of independent developers
contributing to a project, I was talking about a team inside a
company, with a clear leadership and somebody that stablishes standard
workflows and practices, maybe company wide. In this case there is no
agreement, there is training of the team to comply with company/team

standards.

> This is important, because ...
>
> > I remember from my Java coding days that there were a few code
> > "beautifiers" that let you configure every aspect of code presentation
> > (not just indentation) and then reformat a whole project. Even Eclipse
> > introduced a long time ago a code formatter that kept your code
> > correctly formatted according to your coding standards, using a coding
> > style definition that could be installed in every developer machine.
> > Maybe you could take a look to some of them and try to adapt it to
> > puppet code (don't know if it's possible)
>
> > I don't know if people would appreciate such a thing regarding puppet,
>
> ... this technical approach is going to cause you a universe of grief.
>
> The first reason is that when you apply the code reformatting tool you
> just created a commit that rewrote (or most) of the history under your
> user ID.  
>
> This means that tools like blame/annotate can't determine who was
> responsible for individual parts of the code as effectively.
>
> It also means that all your authors have a single point in time around
> which they need to restructure all their outstanding work -- they have
> to merge this new change in, in one big burst of effort.
>

This isn't true, as long as you always use the code reformatting tool
before commiting your changes, and this tool has been used from the
beginning (or at least from some point) of the project.

> > but I think these kinds of tools are great for improving code
> > readability, as all the code for a project (team? company?) is always
> > formatted the same way and after some time you get used to it.
>
> This isn't as bad as what this seems to imply, though, which is running
> this sort of tool on a regular basis.  Ouch!
>
> Every time you reformat code you cause extra work for the other authors,
> which is not going to be appreciated.
>

First of all, code must be reformatted either by authors before they
commit or be automatically formatted by a hook in the version control
software. I don't see how this can cause extra work for the other
authors, as all the code is being formatted the same way.

> Worse, if you don't get agreement on this beforehand imagine what your
> other authors will do: because you reformatted code, they will feel
> they, also, can reformat it.
>

As I told you before, I was talking about a scenario were practices
are imposed rather than agreed. I ask you to think about the other
extreme: let's say you have a large team of developers all working in
the same project and each of them using their own coding "standards".
Believe me, even if the code is good from the thecnical point of view,
the resulting code is a mess and really hard to read.

> So, they run the reformatter to get their own preferred style uniformly
> applied across the codebase, you change it back, and it all ends up with
> someone getting stabbed in a back alley.[1]
>
> So, solve the *social* problem with social tools, not technical ones.
>

Although I agree with you that this is (in part) a social problem, I
don't believe there are only either social or technical problems. All
problems have social and technical aspects. For example, both you and
Ohad seem to imply that version control is a technical problem, and
that isn't my experience at all. I have found developers commiting
uncompilable code at the end of every day because they thought of the
version control system as some kind of backup of their work, or
developers commiting code without updating their working copy before
to check if their code was compiling with the latest additions. So
version control software is a tool that solves a technical problem,
but you have to train people to correctly use the tool, or to use it
the way you want them to use it, and this is the social aspect.

Code formatting works the same way: you have a social aspect of
agreement or training about coding standards, and then you have the
technical problem of getting everybody to comply with the imposed or
agreed standard, and here's where a code formatting tool comes in
handy.

And please, don't tell me you can do this without a code formatting
tool. If you do:
1. Please, take a look at whatever Java code formatting tool you want,
and tell a developer to check for every single aspect the tool
checks... don't be surprised if the developer looks atonished
2. I'll tell you to drop your control version system... after all if
you're man enough to format ALL the code EXACTLY the same way, I guess
you'll be man enough to merge by hand in a shared directory ;o)

> If you do that, and it seems *really* important -- and you can justify
> the technical cost -- then use a reformatter *once* on your codebase.
>

I don't think this is a valid solution at all, as code reformatting is
not for improving readability for someone that eventually happens to
read the code, is for improving readability for people working daily
on the code, who has agreed or been trained on a coding standard.

Best regards
Jose