My editor's fine. I'm being paranoid. In this age the whitespace problem tends to occur for cross-platform programs. And by "problem" I mean the code not looking right. (For C anyways....)
As for developing this thing I was wondering what the preferred method for testing was. I mean, how do I use the development pacman without interfering with Arch's pacman? Also, are there ways to test installation/removal without writing to disk (there's probably a dry run option, better check the man page)? On Mon, 2011-01-17 at 17:03 +1000, Allan McRae wrote: > On 17/01/11 16:23, Westley Martínez wrote: > > Hello I'm Anikom15 and I'm new. You might know me from the Arch Linux > > forums but whatever. > > I have seen you there in between your repeated bannings... > > > I'm interested in helping develop pacman considering the fact I've been > > using the program for so long I figure I should give something back, and > > maybe get better at C coding, too. > > > > Okay, one question: why does the source code use tabs instead of spaces? > > Is there a specific reason as to why? In my experience spaces makes > > everything easier because tabs can mess up alignment if the editor isn't > > set properly. > > How? As long as you stick with the coding standards and always use > tabs there can be no issue. > > > I know what you're thinking, "These new people they come > > in and wanna change everything and then leave". > > I was thinking you need to get a better editor... > > > I don't wanna change > > anything unnecessarily, I'd just like an explanation. Now just between > > you and me I think some other conventions the code is using like return > > statements being written like a function call are stupid as well, but > > those don't have dire consequences like the tabs can potentially have. > > White space issues having dire consequences? It is normally the > non-whitespace issues that you need to worry about. > > > Sorry if I sound a little invasive, I don't collaborate much. > > As with any project, if you want to contribute you need to stick to the > established coding standards. These are unlikely to change unless there > is a very good reason to do so. > > Allan >
