Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#3243 closed Enhancement (worksforme)

Transmission project needs published settings for "indent".

Reported by: Astara Owned by:
Priority: Normal Milestone: None Set
Component: Transmission Version: 1.93
Severity: Normal Keywords: source format
Cc:

Description

It would be *REAL* useful if "you" (project members) could come up with a set of options for the util "indent" that would put a source file into a standardized format, so when edits are made, they can be done without worrying about indentation, and to get them to match, just run indent over the files and it will put them into a standardized format. I wouldn't expect that everyone would prefer my 'preferences', but if we have a tool that can convert back and forth between preferred source formatting styles, then it isn't a big deal which format it used as source files can be converted to anyone's preferred style with a simple command.

The source formatting conventions can either be as they are now, or it can be in a more optimized format for editing and development.

I prefer something closer the linux-kernel style with the exception of the indent level being 8 space/tab. I use 2-3 (I like 2 a bit more as it's more compact, but 3 is a bit more readable in some uncommon situations.

To give an example, indent can use a ".indent.pro" file for it's defaults. I've been using:


--blank-before-sizeof --braces-on-func-def-line --braces-on-if-line --braces-on-struct-decl-line --cuddle-else --cuddle-do-while --continuation-indentation2 --indent-level2 --indent-label2 --parameter-indentation2 --honour-newlines --break-before-boolean-operator --dont-format-comments --dont-break-procedure-type --dont-break-function-decl-args --dont-break-function-decl-args-end --space-after-cast --swallow-optional-blank-lines


Anyway -- I can submit my patches but they'd be against the files having already been run through indent with the above defaults... OR , if you publish defaults you'd want them in, I can run my patched files through that default and then do the diff.

Comments?

Change History (7)

comment:1 Changed 12 years ago by charles

  • Resolution set to worksforme
  • Status changed from new to closed

Transmission's indentation style is a little oddball, I agree. When I started working with it, it took me awhile to use it right.

The bottom line is you should try to submit patches in Transmission's current indentation style. If you want to do your local development in a more traditional indentation style and then pass it through indent or uncrustify to Transmissionifiy it before preparing the diff, I would completely understand your reasoning :)

As for the .indent.pro... I tried this at one point and failed. uncrustify got closer, but in committed so many atrocities that I abandoned it as well. If you would like to give it a shot, be my guest.

comment:2 Changed 12 years ago by Astara

Charles, if you tried to make it work but were not able to, then is closing this with a "works for me" really "accurate"? :-)

I hadn't not heard of 'uncrustify', but it looks like it would have all the abilities of 'indent' (and likely more, if needed), but I'd lean toward 'indent', since it has come included on distro's I've used for the past several-10 years and is likely to already be on more people's system's than uncrustify. There looked to be a useful 'gui' that was referenced on the uncrustify page as well. I've d/l'ed it, but haven't built it or tried it yet.

Regardless -- if the current source isn't easily amenable to reformatting with a source-format 'normalizer' program, then what would be the issues/concerns with doing a wholesale reformatting of the current code set and storing it as a 1-time no-op in the source-control system?

Are you attached to the current format? Who else would have a stake in this type of decision? If there isn't a strong preference, but everyone is going with 'inertia', I'd like to put forth the format as specified by the options I attached to this "incident"/"bug".

Even if there are strong preferences or reasons for wanting the current format, I still believe the inability of the current code format to be easily (programatically) _normalized_, should be considered "undesirable" -- and thus, as a 'bug', or 'rfe'.

I'd regard it as being a 'source problem' along with problems like using raw numbers in switch cases (900-9xx) instead of meaningful numbers like '256*'B'+'l', for switch 'Bl'...

So who are the stake-holders in deciding or giving a yay/nay on source-code normalization. FWIW, I've run indent with the options attached to this issue over the entire source and it seems to run 'just fine' (to the limited extent that my usage is any 'testing').

comment:3 Changed 12 years ago by charles

Every project everywhere prefers that code submitters use the existing indentation format. That is a reasonable request.

If you feel that indent can be used to generate Transmission's indentation style, then you're probably right. I don't have much experience with indent-style tools, and you've got 10 years, so if you want to give it a shot I'm positive you'd get further on it that I did.

It seems like many of our conversations end up debating things that don't affect the end product, such as indentation styles, or whether your ISP blocking transmissionbt.com is transmissionbt.com's problem, or whether requesting client A's feature in client B is a bug report or an enhancement request. IMO we would both be better off spending our time writing code that fixes existing trac tickets.

comment:4 Changed 12 years ago by Astara

As for what other projects do -- most adhere to some standard. Transmission uses inconsistent styles in different places in the code. If that's the standard, then we have a non-issue. If the desire is to have a standard, then a means of making sure the code is in that format is necessary -- but right now, indentation styles are not consistent. I won't bother with trying to make them consistent, as you indicate that what is there is the preferred style.

As for what's determined to be a bug or not, you raised that issue. I'm sorry if my doing anything other than immediately agreeing with you irritates you. That doesn't make for a healthy development environment.

comment:5 Changed 12 years ago by Astara

(p.s. in saying I won't bother to try to make them consistent, I also won't try to make existing code any less consistent than it already is (just to be clear)).

comment:6 Changed 12 years ago by charles

As for what's determined to be a bug or not, you raised that issue. I'm sorry if my doing anything other than immediately agreeing with you irritates you. That doesn't make for a healthy development environment.

I've asked four other Transmission developers / contributors in irc on freenode's #transmission for a reality check on this to make sure I'm not talking out of my ass. All five of us agreed that this is an enhancement request, not a bug.

Anyway. I've tried to be respectful, even in disagreement. Looking at your paper trail on Google I can see you're not someone I want to chase off accidentally, but I honestly don't think the recent topics have been productive. I would be happy for us to steer back to issues that real world users would actually care about, and have spent a great deal of time today both in trac and in private mail try to do exactly that.

comment:7 Changed 12 years ago by livings124

The libtransmission code follows a fairly consistent style as far as I can tell. It would be best to adhere to the existing formatting.

Note: See TracTickets for help on using tickets.