Jump to content

consistency in your code.


Recommended Posts

For the love of everything holy.

Can we have one file charset and one line encoding for the whole of IPB?

Please? If it means you have a locked config on the IDE's your developer's use, so be it, but this is beyond insane, and not only is nothing done about it, it gets worse with every file added.

UTF-8 and n.

Consistency, please.... this is no amateur hour.

Link to comment
Share on other sites

Plus one on line endings being converted to unix line endings.

I haven't experienced the charset issue, but that makes sense to have all files saved in one specific charset aswell. :smile:

They should update their build scripts or svn-deploying script (or whatever) to deal with this.

Link to comment
Share on other sites

Plus one on line endings being converted to unix line endings.

I haven't experienced the charset issue, but that makes sense to have all files saved in one specific charset aswell. :smile:

They should update their build scripts or svn-deploying script (or whatever) to deal with this.

Half of IPB is distributed in iso-8859-1, the other half UTF-8.

RE: the line endings, having it report wrong in SVN is bad enough, but when you pull down a file to edit in ftp, save, and re-upload, only to have it implode into a one-line file you have to reupload from source simply because you have the common sense to save files in Unix line endings, but the file you opened is not, is seriously not a good or happy thing.

Link to comment
Share on other sites

I like that the type of line endings used in our files results in a topic starting with "For the love of everything holy.".

Sometimes editors just don't behave. All of us are set to use utf-8 with unix line endings, and we double checked following this topic. Sometimes an editor just doesn't listen for some reason, however. As we get into 4.0, we'll ensure this is outlined again in our coding standards document internally.

Link to comment
Share on other sites

Sometimes editors just don't behave. All of us are set to use utf-8 with unix line endings, and we double checked following this topic. Sometimes an editor just doesn't listen for some reason, however. As we get into 4.0, we'll ensure this is outlined again in our coding standards document internally.

Isn't SVN able to handle this on push aswell? I'm pretty sure git does. Where you can have a gitattributes-file inside the repo (so everyone shares it) and then it ensures all pushes from everyone shares the line ending regardless of editor.

It would probarbly be a good idea to do a convert for all files and do a new push (whether it's 3.4.X or 4.0) just so you know you ensured all files are in unix.

edit: I forgot that I can't use STD when quoting, so post was bugged for a second

Link to comment
Share on other sites

I will like to suggest IPB creating a similar Developer Certificate like Magento. This has huge benefits and the most important one reside on code unification. Ryan can also explain , in order to get Magento Developer Certificate , you need to know Magento inside out and even there can be different coding standarts once you know Magento , the structures will always be similar. Which reduces the conflicts within third party modifications.

Developers and IPB customers can also benefit from this as a certified developer can always ask the exact price he want and customers can choose easily from certified developers.

Link to comment
Share on other sites

I will like to suggest IPB creating a similar Developer Certificate like Magento. This has huge benefits and the most important one reside on code unification. Ryan can also explain , in order to get Magento Developer Certificate , you need to know Magento inside out and even there can be different coding standarts once you know Magento , the structures will always be similar. Which reduces the conflicts within third party modifications.

Developers and IPB customers can also benefit from this as a certified developer can always ask the exact price he want and customers can choose easily from certified developers.

They are working on this already, it just hasn't been completely finalized. A handful of developers have already submitted their application.



Where I work we catch this stuff during code review...

Code review... wtf is that? ;)

Link to comment
Share on other sites

They are working on this already, it just hasn't been completely finalized. A handful of developers have already submitted their application.

Where have they posted the news on that by the way? I haven't found any information on it. And I'm really sure I looked carefully.

Link to comment
Share on other sites

Main things I wish are 1. it would be simpler tot rack down the trail of files being used for a particular file (I have to go all voer the place tracking down where certain things are done) and 2. they would fix all the xhtml errors which never seems to go down in count from release to release. I stopped paying as much attention to my own xhtml errors because I know even when I have zero (which i probably do still have zero in most apps) it won't mater much because I can't say they're xhtml valid since ip.board files themselves will have a lot of errors.

Link to comment
Share on other sites

Main things I wish are 1. it would be simpler tot rack down the trail of files being used for a particular file (I have to go all voer the place tracking down where certain things are done) and 2. they would fix all the xhtml errors which never seems to go down in count from release to release. I stopped paying as much attention to my own xhtml errors because I know even when I have zero (which i probably do still have zero in most apps) it won't mater much because I can't say they're xhtml valid since ip.board files themselves will have a lot of errors.

You know IP.Board isn't XHTML right ?

It's an inconsistent match of XHTML and HTML5

Link to comment
Share on other sites

It "should" all be xhtml valid is my point and many versions bsck they said they were going to get rid of all the xhtml errors. Personally, I don't know how many people care if something is 100% xhtml valid, but I'm sure there are some.

It shouldn't be XHTML validated, it's intended to be HTML5

Link to comment
Share on other sites

Main things I wish are 1. it would be simpler tot rack down the trail of files being used for a particular file (I have to go all voer the place tracking down where certain things are done) and 2. they would fix all the xhtml errors which never seems to go down in count from release to release. I stopped paying as much attention to my own xhtml errors because I know even when I have zero (which i probably do still have zero in most apps) it won't mater much because I can't say they're xhtml valid since ip.board files themselves will have a lot of errors.

1) debug_print_backtrace(); :) It's a built in PHP function (it won't show every file loaded, but it shows the backtrace of files that lead to the point where you add that line)

Link to comment
Share on other sites

stoo, yawn, I said it "should" be xhtml valid. One of the main things people had complained about in the past was the importance that everything validate in xhtml and in some bug reports it was stated that the errors would be taken care of. Any decision to use something other than xhtml has nothing to do with my point when I say "should". The goal at one point was clearly to have everything validate in xhtml.

Thanks, Brandon. Although, I am still not totally sure it will do what I want. Let's say i use some built in function of ip.board and then afterwards i put that line in my function, it would trace back through everything used from the begiinning of my function to that point, including what was accessed in the ip.board function? (edit or actually in the case of an app, it would backtrace to even way before my function I guess?).

Link to comment
Share on other sites

I'll repeat that incase you didn't understand it the first time.

stoo, yawn, I said it "should" be xhtml valid. One of the main things people had complained about in the past was the importance that everything validate in xhtml and in some bug reports it was stated that the errors would be taken care of. Any decision to use something other than xhtml has nothing to do with my point when I say "should". The goal at one point was clearly to have everything validate in xhtml.



It shouldn't be XHTML validated, it's intended to be HTML5

Link to comment
Share on other sites

edit: nevermind, this is a waste of time. Really also, though, it doesn't validate for whatever the doc type is, anyway. I never really noticed that the validator is validating based on doc type, not only xhtml. So the point is it still has errors, not just for xhtml but whatever it's checking, so html5 I guess. It would be good if it validates.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...