| Ternary Operator |
[Sep. 1st, 2006|01:23 pm] |
The ternary operator should not be used as an if-else replacement for calling methods... for example, please do not do this:
$foo ? LJ::do_something() : LJ::do_something_else();
For clarity, please use the following form:
if ($foo) {
LJ::do_something()
} else {
LJ::do_something_else()
}
The ternary should be used only in constructions that involve relatively straightforward value substitutions. For example, the following would be fine:
LJ::call_a_function($u, $u->{journaltype} eq 'Y' ? 1 : 0);
Which passes through a 1 if the account is syndicated. It is short and easy to read. Please do not use ternaries in mid line if you're going to end up with a mess, like this:
LJ::call_another_function($u, $u->{journaltype} eq 'P' && $u->{status} eq 'A' && $u->{statusvis} eq 'V' ? ($u->prop('opt_gimmenews') ? 1 : 0) : 0));
Please instead use the following form, breaking it out for readability:
my $is_validated_user = $u->{journaltype} eq 'P' && $u->{status} eq 'A' && $u->{statusvis} eq 'V' ? 1 : 0;
my $wants_news = $is_validated_user && $u->prop('gimmenews') ? 1 : 0;
LJ::call_another_function($u, $wants_news);
Avoid nested ternaries while you're at it. |
|
|
| email encodings |
[Aug. 25th, 2006|10:08 am] |
|
When sending out email: make sure to specify the charset as 'utf-8'. Otherwise, Russian/Ukrainian/non-English text gets parsed as ASCII, and ends up looking garbled. |
|
|
| site schemes |
[Jul. 24th, 2006|08:45 pm] |
When building pages, it's probably wise to make them scheme-independent; rather than hardcoding colors or stylistic choices that apply to one scheme, we should use scheme-provided properties and options (eg, using <?p p?> instead of <p></p>).
This helps us to make sure that pages are easily extended to other schemes, and helps to avoid the situations where a page looks great in one scheme but ass in another. (It also makes it easier for us to build new site schemes without having to do cleanup on pages that were styled/colored for a certain scheme.) |
|
|
| Deleting and changing translation strings |
[May. 23rd, 2006|05:43 pm] |
Deleting strings: Deadphrase them!
When a string is no longer used anywhere on the site, remove it from en.dat or en_LJ.dat and add the dead string to deadphrases.dat or deadphrases-local.dat, respectively. If the string is in both en.dat and en_LJ.dat (because it's used on a page in the livejournal repository but says something different for LiveJournal.com), then delete the string from en.dat and add it to deadphrases.dat--you don't need to delete it from en_LJ.dat.
Changing strings: Create new ones; don't edit them!
If you need to change a string in the translation file and not on the site, remove the old string, deadphrase it (as described above), and create a new one; don't edit strings in the translation files. Editing an existing string in the translation file (that's already live on the site) will not update it on the site. Even if you're positive it isn't live on LiveJournal yet, it's bad practice to edit the string since other sites may have put the en.dat file live for themselves. So, just create a new string--it's the option least likely to cause problems. |
|
|
| Class method calls |
[Apr. 10th, 2006|06:30 pm] |
I noticed in Brad's latest commit calling a class method from an instance method in this form:
+ __PACKAGE__->preload_rows([ $self ]) unless $self->{_loaded_row};
Is this the new preferred way to call class methods from instance methods? I've never seen it like this before. |
|
|
| VI settings that make LJ happy |
[Mar. 9th, 2006|11:57 am] |
Here is most of the contents of my .vimrc file
>>>>>>>>>>>>>>
syntax enable
set cindent smartindent smarttab showmatch shiftwidth=4
set expandtab
au BufRead,BufNewFile *.bml setfiletype perl
set backup
set list listchars=trail:_
highlight SpecialKey ctermfg=DarkGray ctermbg=yellow
<<<<<<<<<<<<<<<
The smart indent isn't always so smart, or maybe it's the smart tab, but it works ok most of the time. Shiftwidth and expandtab make sure the indents are made up of 4 spaces.
Backup makes a backup file named filename~, which might be useful on occasions when your main file gets overwritten by accident.
Listchars and Highlight SpecialKey combined mark trailing whitespace with a grey underscore on a yellow background, quite easy to notice if you are working against a black background. Also tab characters show up as grey ^I on a yellow background.
Some of these settings can perhaps be improved on, but this works fairly well for me. |
|
|
| Trailing Whitespace |
[Mar. 23rd, 2006|11:51 pm] |
Remember, trailing whitespace is contagious and can easily take over a file much like North American Ivy! Be a good camper and don't commit trailing whitespace. If you're using emacs, I recommend adding this to your .emacs file.
(setq-default show-trailing-whitespace t)
(setq-default default-indicate-empty-lines t) |
|
|
| Don't hard-code URLs in translation strings |
[Mar. 28th, 2006|10:45 pm] |
In the large majority of cases, you should never hard-code URLs in translation strings. Use the variable [[aopts]] ('aopts' => "href='$LJ::SITEROOT/page/'") instead. This way, URLs can be changed (in the code) without having to worry about translations needing to update their strings to get the new URLs.
Exception: If a string is on a livejournal page but needs to link to an ljcom page, then the string without the link should be in en.dat, and the string with the hard-coded URL link should be in en_LJ.dat (to avoid putting links to ljcom pages in livejournal pages). For example, there may be a feature that is only available to paid accounts on LiveJournal, and a string on a livejournal page that says this. So, in en.dat, the string would be something like, "This feature is not available to your account type.". In en_LJ.dat, the string would be something like, "This feature is only available to <a href="http://www.livejournal.com/paidaccounts/">Paid Accounts</a>." When the code makes it possible, it's a good idea to use <?siteroot?> instead of "http://www.livejournal.com/", so dev environments can get links to local pages and not those on LiveJournal. |
|
|
| Empty parens, calling functions.... |
[Mar. 9th, 2006|03:35 pm] |
Don't do this:
&foo();
That's old.
You can do this:
&foo;
But only if you REALLY know why. I bet you'll never need to.
Use empty parens when calling global functions:
LJ::get_remote();
but not when calling methods on objects:
$foo->accessor; |
|
|
| Nearby Code |
[Mar. 9th, 2006|08:44 am] |
Follow the conventions of code around you. You want to blend in. You don't want us to come along in 6 months and see three different people's style, block-by-block.
However, that doesn't mean you shouldn't clean up old/ugly code using wrong APIs or disobeying whitespace rules, etc:
http://community.livejournal.com/lj_codingstyle/1110.html -- camping rule |
|
|
| navigation |
| [ |
viewing |
| |
most recent entries |
] |
| [ |
go |
| |
earlier |
] |
| |
|
|
![[info]](http://l-stat.livejournal.com/img/community.gif?v=92.2){kind=small}
lj_codingstyle