Если предположить, что я правильно понял логику, то вот решение data.table
.
Перефразируя логику: если человек (идентифицированный как ID
) когда-либо имеет chil.int + year %in% year[event == 1]
, то все его / ее ряды получают 1
в new.col
. Это если любой из year + chil.int
равен любому году, в котором происходит событие (хотя в этом примере даже случается максимум один раз для каждого ID
).
library(data.table)
setDT(df_raw)
df_raw[, new.col := as.integer(any((chil.int + year) %in% year[event == 1])), by = ID]
df_raw
ID chil.int event year new.col
1: A 3 0 2013 1
2: A 2 0 2014 1
3: A 1 0 2015 1
4: A 4 1 2016 1
5: A 3 0 2017 1
6: A 2 0 2018 1
7: B 5 0 2010 1
8: B 4 0 2011 1
9: B 3 0 2012 1
10: B 2 0 2013 1
11: B NA 1 2015 1
12: C 1 0 2015 0
13: C 1 0 2016 0
14: C NA 0 2017 0
Некоторое время назад я использовал
if <cond> then
begin
ShowMessage('balablala');
exit;
end;
Но теперь я следую стандарту
if <cond> then
begin
ShowMessage('balablala');
exit;
end;
Я лично использую:
if Condition then
begin
DoThis;
end else
begin
DoThat;
end;
См. руководство по стилю Object Pascal.
В составном объекте, если операторы, помещенные каждое разделение элемента операторы на новую строку: Пример:
// INCORRECT
if A < B then begin
DoSomething;
DoSomethingElse;
end else begin
DoThis;
DoThat;
end;
// CORRECT
if A < B then
begin
DoSomething;
DoSomethingElse;
end
else
begin
DoThis;
DoThat;
end;
Вот еще несколько изменений, которые считают допустимыми:
// CORRECT
if Condition then
begin
DoThis;
end else
begin
DoThat;
end;
// CORRECT
if Condition then
begin
DoThis;
end
else
DoSomething;
// CORRECT
if Condition then
begin
DoThis;
end else
DoSomething;
Ха! Возьмите это!;)
try
if Condition1
or ( Condition2
and Condition3) then
begin
DoSomething
DoSomeMore;
end
else if Condition4 then // I only do this if the nested "if" has "case"-like characteristics
begin // otherwise the if would obviously be indented and on its own line
DoSomethingElse;
if Condition5 then
begin
DoThisToo;
DoFoo;
end;
end
else
DoTheWholeShebang;
case Whatever of
A: DoIt;
B, C, D:
begin
DoSomethingSlightly;
MoreComplicated;
end;
else
begin
DoWhatever;
DoLastResort;
end;
end;
except
on ESomeException do
begin
HandleIt;
raise;
end;
on ESomeOtherException do
DealWithIt;
else
DoWhateverItTakes;
end;
Странно, хотя, при записи на языках фигурных скобок я также предпочитаю запаздывающее расположение фигурной скобки:
if (condition) {
doSomething;
} else {
doSomethingElse;
}
Я - программист выходных дней так, будучи единственным, работающим над проектами, я могу позволить себе не следовать определенной конвенции кодирования, удачной меня.
Когда дело доходит до структурного выделения Источника вдохновения удобочитаемости кода очень полезно. CnPack имеет подобную функцию, я не путаю.
Даже если это - отдельный оператор в if
, Я всегда использую составной объект begin-end
предотвратить будущий беспорядок.
Также я поместил // if
после каждого end;
.
if A < B then
begin
DoSomething;
end; // if
То же самое для других операторов:
with qryTemp do
begin
First;
while not Eof do
begin
if (A < B)
or (C < D)
begin
DoSomething;
end else
begin
DoSomethingElse;
end; // if-else
Next;
end; // while
end; // with
Для C# я следую Конвенциям Кода для составных операторов стиля Языка программирования Java.
if (condition) {
statements;
} // if
if ((condition1 && condition2)
|| (condition3 && condition4)
||!(condition5 && condition6)) {
doSomethingAboutIt();
} else {
doSomethingElse();
} // if-else
И для Delphi и для C#, соединяющиеся логические операторы прибывают в начале следующей строки.
Я всегда выстраиваю в линию Начинание/Заканчивание как в Вашем примере. (Кроме у меня было бы Начинание/Заканчивание вокруг оператора For также - на всякий случай Вы идете, добавляет код позже.)
Так или иначе, если Ваш код является несколькими уровнями глубоко, то действительно не имеет значения, куда Вы помещаете Ваш начинать/заканчивать, поскольку это слишком сложно. При нахождении себя, скажем, 3 уровнями глубоко остановитесь и упростите. Создайте sub стандартные программы для чистки вещей.
CodeComplete является лучшим справочником на этом точном виде вещи. Если Вы не изучите что-то, читая ту книгу, то я съем свою шляпу.
Используйте некоторое средство форматирования кода как Формат кода ДЖЕДАЯ из http://jedicodeformat.sourceforge.net/
Это все довольно забавно. У меня есть свой собственный особенный способ выравнивания, которое, странно, я использую на нескольких языках, включая Паскаля, C, и даже КОБОЛ (хотя не в долгое время для тот одного).
Я думаю, что увидел его в первый раз в классе от Ken Orr. Моя версия также очень похожа на наличие правила вне игры (подобный Python и F#), где Вы могли просто использовать расположение с отступом для показа вложения.
Во всяком случае вот то, как я делаю пример:
begin if x = y
then begin (* stack to avoid getting too much indentation *)
...
...
end
else for i := 0 to 20
do begin
...
...
end;
end;
и да, разновидность C/C ++/Java/C# была бы чем-то как
{ if (x == y)
{ ... /* Space as if 'then' is there */
...
}
else for (int i = 0; i<21; i++)
{ ... /* space as if 'do' is there */
...
}
}
Я использую это много. Вы могли сложить {и} тот же путь я действительно начинал и заканчивался, но я нахожу более приятным смочь увидеть вниз край и подтвердить соответствующие скобки и окончание группы с отступом. Я варьируюсь, чтобы помешать расположению с отступом быть чрезмерным и стараться не иметь слишком многих "{" и "}" положение одного в море пробела.
Я не проповедую христианство этому. Никто не жаловался на способность считать его. Помещение "{" на конце строки походит на пережиток от препроцессоров Ratfor и такого, вида способа, которым Python требует (более - приятный) ":" в местах. Я не хочу должным быть сканировать неровный правый край вниз код, когда я могу использовать выравнивание на левых краях более полезно.
Поскольку мы говорим здесь, YMMV
Лично, я предпочитаю сжимать присоединяющиеся операторы на одной строке. Например. end else
на одной строке. Делает это более ясным, что следующий блок операторов связан с текущим.
Я никогда не писал бы код (Ваш второй пример) тот путь. Это было бы или (предпочтено)
begin
if x = y then begin
...
end
else begin
for i := 0 to 20 do begin
...
end;
end;
end;
или
begin
if x = y then begin
...
end
else for i := 0 to 20 do begin
...
end;
конец;
Иногда я использую такое сворачивание (в качестве во втором случае), чтобы объединиться если и попытка.. наконец.
x := GetMeTheObject;
if assigned(x) then try
...
finally FreeAndNil(x); end;
Это спросили прежде. например, c-coding-standard-best-practices.
Я склонен всегда выстраивать в линию мой, ЕСЛИ и ЕЩЕ и располагают мой с отступом НАЧИНАТЬ/ЗАКАНЧИВАТЬ блок. Если у меня есть условие нескольких, ЕСЛИ, я повреждаю это в несколько строк. Если я нахожу мой сам получение к глубокому, то я заново продумал то, что я кодирую или осуществляю рефакторинг в несколько методов. Таким образом, мой код похож на следующее:
if condition1 then
begin
// do something
end
else // not condition1
begin
// do something else
end;
или более сложное, если условные выражения.
if condition1 or
condition2 or
condition3 and
( condition4 or
condition5 )
then
begin
// do something
end
else // not conditions
begin
// do something else
end;
Стандарт в мире C должен выровнять закрывающие фигурные скобки с любым стартовый оператор:
if (I am nuts) {
Psychiatry
}
или даже помещенный вводная фигурная скобка на ее собственную строку:
if (I am nuts)
{
Psychiatry
}
В некоторых стилях фигурные скобки имеют другое добавление отступа:
if (I am nuts)
{
Psychiatry
}
или даже
if (I am nuts)
{
Psychiatry
}
Я использовал первый стиль в течение долгого времени в Perl, и это еще было моим путем к продолжение:
if (I am nuts) {
Psychiatry
} else {
I am free
}
но будучи подвергнутым Lisp, я не вижу дополнительного значения от помещения фигурных скобок на их собственной строке, когда я уже делаю отступ правильно:
if (I am completely nuts) {
Psychiatry }
else {
I am free }
У меня нет надежды изменить традиционные пути C с этими мыслями, все же.
Как в стороне примечание, Python вывел фигурные скобки в целом и полагается только на добавление отступа, однако это заходит слишком далеко по моему скромному мнению, когда это приводит к таким смешным вещам как эта лямбда, может иметь только один оператор.
Я склонен делать это в Delphi:
if a=b then begin
c;
end else begin
d;
end;
if x=y then z;
просто, потому что я нахожу это более читаемым, чем с дополнительными разрывами строки. Очевидно, если я буду работать с другими, то я буду использовать любые стандарты, которые мы согласуем (или безотносительно текущего использования кодовой базы), но когда я - единственный, кто работает над этим (как в, персональные проекты), затем я делаю это как это.
У всех есть различные предпочтения. В моем случае я изучил Modula-2, прежде чем я изучил Паскаля. Modula-2 имеет, не НАЧИНАЮТ ключевое слово и необходимый КОНЕЦ для каждого блока. Таким образом, код мог бы быть похожим на это (Modula-2, оказывается, чувствителен к регистру с прописными ключевыми словами):
IF x = y THEN
....
END;
Когда я начал кодировать в Паскале, это стало:
if x = y then begin
....
end;
Таким образом код смотрел больше как то, что я привык видеть, все еще будучи в области приемлемого кода Паскаля.
Для меня эти ранние впечатления влияли на мою предпочтительную фигурную скобку и стиль отступа для фактически всех других языков, с которыми я работал. Нет действительно никакой конкретной "нормы" для кода C#, так же, как нет ни одного для C или Паскаля.
Единственное реальное правило следовать является этим: При работе над существующим кодом используйте стиль, который уже существует. При работе над новым кодом используйте предпочтительный стиль.
Кто-то отправил это, они запишут следующее:
if x=y then z;
Теперь это, которое я действительно не люблю, и это не имеет никакого отношения к эстетике. Позволяет предполагают, что x, y и z являются функциями, Если я ступаю через код, вышеупомянутые средства, я не могу переступить через X и Y и ступить в z.
1 if x=y then
2 Z;
Я могу теперь ступить в строку 2, не ступая в строку 1.
Я раньше использовал "свисание", начинаются в Delphi:
if (SomeCondition) then begin
...
end;
Достаточно странно я не сделал с C, потому что я нашел это более читаемым:
if (SomeCondition)
{
...
}
Через некоторое время я прекратил пытаться сохранить одну строку тут и там в пользу удобочитаемости:
if (SomeCondition) then
begin
...
end;
Я также использую явный, начинают/заканчивают блоки, где я думаю, что это улучшает удобочитаемость. Я не должен быть "умным". Я должен смочь следовать за намерением кода сразу. Что еще более важно, также - все, кто мог бы читать/поддерживать его.
if x = y then
begin
...
...
end
else
begin
for i := 0 to 20 do
begin
...
...
end;
end;
Я обычно не беспокоюсь, если существует, очевидно, отдельный оператор
if (SomeCondition) then
...
Просто позвольте вашей среде IDE отступать для вас в большинстве случаев.
Я нахожу код более читаемым, когда ключевые слова (ключевые как синтаксически, так и логически) максимально раскрыты.
Это настолько важно для меня, что иногда я прибегаю (ИМХО) к совершенно нестандартным вещам.
Вот как это выглядит:
if (condition) then begin
statement;
...
statement; end
else begin
...
end;
Я признаю, что это может сделать изменение кода немного менее удобным. Просто я нахожу «висячий» end
в середине оператора if
и выровнен так же, как if
, что несколько сбивает с толку. Если это end
, он должен быть последним (для оператора), иначе я ожидаю либо else
, либо начало следующего оператора в этой позиции.
И я обычно не допускаю, чтобы это было, когда блок then
является составным, а else
является одним оператором. Для меня никогда не было проблемой инвертировать условие и переставить блоки. Тем более, что я довольно скупердяй, когда дело доходит до обертывания одного оператора с помощью begin ... end
. По моему мнению и опыту, изобилие «начало-конец» чаще всего является избыточным «начало-конец».Хотя мне нравится, когда оператор имеет явное конечное ключевое слово, поэтому case
и repeat
— мои фавориты на все времена. :)
Еще одна вещь о if
s (и while
s в этом отношении) заключается в том, что в случае многопалубного условия я склонен размещать then
(do
) на следующей строке и выровнено по начальному ключевому слову оператора.
Вот так:
if (some_long_conditional_expression) or
(some_other_long_conditional_expression) or
(some_even_longer_conditional_expression)
then
Exit;
Кроме того, есть некоторые другие вещи, уже упомянутые здесь, в которых я не чужой, например, однострочные else if
s (когда это уместно) или for .. .. делайте с... делайте попытки
s (да, это снова может иметь какое-то отношение к моей скупой натуре, упомянутой выше).
В целом, возможно, я слишком сильно полагаюсь на подсветку кода и отступы, особенно на последнее. Возможно, если бы не отступы, я бы предпочел всегда выделять begin
s.
Еще один момент: чей-то стиль форматирования, скорее всего, может быть вызван его стилем программирования. Например, некоторые люди ненавидят очень большие подпрограммы и склонны учитывать, когда это возможно, в то время как другие предпочитают концентрироваться на самом коде и не обращать внимания на эти несколько составных блоков, охватывающих экран - я считаю, что это очень разные подходы, которые могут привести к различным привычкам форматирования. .