Обсуждение: Removing all whitespaces in ODBC code
Hi all, Please find attached a patch to remove all the whitespaces in pgodbc code. Before having a deeper look to the ODBC code to remove all the old protocols and try to clean up outdated code, it would be nice to commit that. My environment is made to detect automatically whitespaces, so not removing them would only generate noise on my patches. Thanks, -- Michael
Вложения
On 03/11/2014 07:44 AM, Michael Paquier wrote: > Hi all, > > Please find attached a patch to remove all the whitespaces in pgodbc > code. Before having a deeper look to the ODBC code to remove all the > old protocols and try to clean up outdated code, it would be nice to > commit that. My environment is made to detect automatically > whitespaces, so not removing them would only generate noise on my > patches. Thanks, committed together with many additional whitespace fixes: * Remove all instances of <space><newline>. I think this is what your patch did. * Remove all instances of <tab><newline>. * Remove unnecessary spaces from indentation: <space><tab> * Misc indentation fixes spotted while fixing those other things * Added/removed a few curly braces from if-statements with a one line action, for clarity * Removed empty lines before EOF. * Also cleaned up whitespace in non-code files, like readmes and .bat files. * Removed bogus byte-order-marks from psqlodbcm.wxs and psqlodbcm_cpu.wxs. They were bogus because the files are UTF-8 encoded. (didn't notice this until I reviewed the changes in git-diff; my editor fixed automatically). * Remove the 'x' flag from file permissions of a few header files, for consistency with all the other files. These were things that git diff complained about, when I did: git diff 0183b4605ee4ad76851cea69587d240492041705 --check That commit is the first-ever commit in the repository, the idea was to get a diff that covers the whole source tree. It might've missed some lines that have not been changed since the initial commit, but I couldn't figure out how to run the check that "git diff --check" does across the whole source tree, rather than a diff. There are some files related to the installers that contain DOS-style newlines, <CR><LF>. I'm itching to fix those to Unix-style, but refrained because I don't really know Windows, so I don't know if that would be wrong or problematic. Anyway, the source tree is now in a much better shape. Still a lot of stylistic issues I'd like to fix, but that'll do for the whitespace. - Heikki
On Tue, Mar 11, 2014 at 6:01 PM, Heikki Linnakangas <hlinnakangas@vmware.com> wrote: > On 03/11/2014 07:44 AM, Michael Paquier wrote: >> >> Hi all, >> >> Please find attached a patch to remove all the whitespaces in pgodbc >> code. Before having a deeper look to the ODBC code to remove all the >> old protocols and try to clean up outdated code, it would be nice to >> commit that. My environment is made to detect automatically >> whitespaces, so not removing them would only generate noise on my >> patches. > > > Thanks, committed together with many additional whitespace fixes: > > * Remove all instances of <space><newline>. I think this is what your patch > did. > * Remove all instances of <tab><newline>. > * Remove unnecessary spaces from indentation: <space><tab> > * Misc indentation fixes spotted while fixing those other things > * Added/removed a few curly braces from if-statements with a one line > action, for clarity > * Removed empty lines before EOF. > * Also cleaned up whitespace in non-code files, like readmes and .bat files. > * Removed bogus byte-order-marks from psqlodbcm.wxs and psqlodbcm_cpu.wxs. > They were bogus because the files are UTF-8 encoded. (didn't notice this > until I reviewed the changes in git-diff; my editor fixed automatically). > * Remove the 'x' flag from file permissions of a few header files, for > consistency with all the other files. > > These were things that git diff complained about, when I did: > > git diff 0183b4605ee4ad76851cea69587d240492041705 --check > > That commit is the first-ever commit in the repository, the idea was to get > a diff that covers the whole source tree. It might've missed some lines that > have not been changed since the initial commit, but I couldn't figure out > how to run the check that "git diff --check" does across the whole source > tree, rather than a diff. > > There are some files related to the installers that contain DOS-style > newlines, <CR><LF>. I'm itching to fix those to Unix-style, but refrained > because I don't really know Windows, so I don't know if that would be wrong > or problematic. > > Anyway, the source tree is now in a much better shape. Still a lot of > stylistic issues I'd like to fix, but that'll do for the whitespace. Thanks a lot! Don't we want to add as well a .gitattributes file in a fashion similar to Postgres itself? I imagine that it would greatly help to continue keeping the code clean. -- Michael
On 03/11/2014 12:16 PM, Michael Paquier wrote: > Don't we want to add as well a .gitattributes file in a > fashion similar to Postgres itself? I imagine that it would greatly > help to continue keeping the code clean. Yeah. Not sure what exactly we'd want to put there. At least ignore trailing whitespace in the expected output files, I guess. Don't know what to do about the files with DOS line endings; do we want to keep that, or convert the all to Unix-style line endings for consistency? How would that work in a Windows environment? Given that all the source files already use Unix line endings, I'd guess that it would be fine, but I'm not familiar with the tools we use in the installers. Got a patch? - Heikki
On Wed, Mar 12, 2014 at 4:14 PM, Heikki Linnakangas <hlinnakangas@vmware.com> wrote: > On 03/11/2014 12:16 PM, Michael Paquier wrote: >> >> Don't we want to add as well a .gitattributes file in a >> fashion similar to Postgres itself? I imagine that it would greatly >> help to continue keeping the code clean. > > > Yeah. Not sure what exactly we'd want to put there. At least ignore trailing > whitespace in the expected output files, I guess. Don't know what to do > about the files with DOS line endings; do we want to keep that, or convert > the all to Unix-style line endings for consistency? How would that work in a > Windows environment? Given that all the source files already use Unix line > endings, I'd guess that it would be fine, but I'm not familiar with the > tools we use in the installers. > > Got a patch? I imagined the attached. Thanks, -- Michael