Топ 10 очень, очень очень важные темы для обсуждения

Некоторые вещи очень, очень, очень, очень, очень важные. Таких как Джон Клиз .

То же самое верно для пробелов:

Да. 1080 очков Reddit Karma (так срочно нужно!) Всего за 23 часа. Это на несколько порядков лучше, чем у любого из наших — как мы ошибочно думали — очень глубокого и интересного технического понимания Java и SQL .

Тема интереса была юмористическим трактатом о том:

for (int i=0; i<LENGTH; i++)

… или это:

for (int i = 0; i < LENGTH; i++)

… должно быть предпочтительным. Очевидно, что оба варианта совершенно неверны. Правильный ответ:

for
(   int i = 0
;   i < LENGTH
;   i++
)

Читайте полный трактат здесь .

Но в какой-то момент обсуждение пробелов становится устаревшим. Нам нужны новые очень очень важные темы для обсуждения, а не исправления ошибок. В конце концов, выходные неизбежны, и мы не знаем, о чем еще говорить.

Вот почему мы сейчас публикуем …

Топ 10 очень, очень очень важные темы для обсуждения

Вот так…

0. Пробелы

ОК, это было легко. У нас это уже было. Хотите участвовать? Очень интересное обсуждение Reddit все еще горячо .

1. Haskell лучше, чем [ваш язык]?

Согласно TIOBE , Хаскелл занимает 38 место.

И, как мы все знаем, фактическая доля рынка (в случае Haskell абсолютно никакой) любого языка программирования обратно пропорциональна количеству времени, затрачиваемого на reddit, на обсуждение важности указанного языка и того, как этот язык полностью превосходит один рейтинг 1-2 выше на TIOBE, например. Какой будет Луа.

Итак, я хотел бы пригласить вас присоединиться к нашим друзьям по блогам ниже к очень очень интересной дискуссии о …

Теперь, конечно, мы могли бы расширить дебаты и сравнить функциональное программирование с ОО-программированием в целом, прежде чем углубляться в то, почему Scala НЕ является функциональным языком программирования , не говоря уже о Java 8 .

О, и вы думаете, что ваш диалект Haskell или Lisp недостаточно хорош, так что вы должны бросить свой собственный? Продолжайте ( сразу после проверки этого контрольного списка! )

Такие отличные темы. Так мало времени.

2. Новые строки и комментарии

Помните наш собственный пост в блоге о добавлении ключевых слов в новые строки ? Да, мы предпочитаем:

// If this
if (something) {
    ...
}
 
// Else something else
else {
    ...
}

Точно. Потому что это позволяет писать комментарии там, где они принадлежат: рядом с соответствующим ключевым словом и всегда выровнены по одному столбцу. Это приводит нас к следующему очень интересному вопросу: должны ли мы вообще добавлять комментарии в код? Или чистый код самодокументируется ?

И мы говорим, почему да, конечно, мы должны прокомментировать. Как, черт возьми, кто-нибудь когда-нибудь вспомнит обоснование чего-то подобного ??

// [#2744] DB2 knows the SELECT .. FROM FINAL
// TABLE (INSERT ..) syntax
case DB2:
 
// Firebird and Postgres can execute the INSERT
// .. RETURNING clause like a select clause. JDBC
// support is not implemented in the Postgres JDBC
// driver
case FIREBIRD:
case POSTGRES: {
    try {
        listener.executeStart(ctx);
        rs = ctx.statement().executeQuery();
        listener.executeEnd(ctx);
    }
    finally {
        consumeWarnings(ctx, listener);
    }
 
    break;
}

Взято со страницы «взлом JDBC» .

3. Конец DBA

Теперь это очень интересная тема, которая интересна не только разработчикам, которые настолько хорошо разбираются в продуктивных системах, но и очень интересна для рабочих групп. Потому что, как мы все знаем, администратор базы данных мертв ( снова ).

Для тех из вас, кто упустил эту очень интересную тему, знайте, что все это началось (снова), когда великие дебаты по NoSQL против SQL были инициированы блестящими умами и поставщиками действительно альтернативных систем. Какие в настоящее время начинают внедрять SQL , потому что , по- видимому, хорошо … _{SQL не все , что плохо} :

История NoSQL в соответствии с @markmadsen #strataconf pic.twitter.com/XHXMJsXHjV

— Эдд Дамбилл (@edd)
12 ноября 2013 г.

Пожалуйста, займитесь еще несколькими дискуссиями о лучшем и единственно верном способе решения проблем с базами данных. Потому что ваше мнение имеет значение!

4. JSON полностью лучше XML

Конечно, это является! Потому что … потому что … ошибаться Потому что это позволяет мне структурировать данные иерархически. Вааааит секунду …

Я люблю JSON. Это дает людям возможность воссоздать самые глупые идеи эпохи XML, но с помощью фигурных скобок вместо угловых скобок.

— Том Моррис (@tommorris)
21 июля 2014 г.

Dayum.

Вы говорите, JSON и XML это то же самое !?

Но MongoDB и PostgreSQL позволяют мне хранить JSON. Ой, подожди. Они пытались хранить XML в базах данных , еще в 90-х годах !? И это не удалось? Ну, конечно, это не удалось, потому что XML отстой, верно? (по сути, это еще один способ сказать, что я никогда не понимал XSLT, XQuery или XPath или даже не слышал о XProc, и я просто ругаю по поводу угловых скобок и пространств имен)

Давайте дальше обсудим этот вопрос. Я чувствую, что мы близки к окончательному решению по этой теме.

Говоря о JSON …

5. фигурные скобки

О, МОЙ БОГ! Это самая интересная из всех тем. Должны ли мы поставить открывающую скобку:

На той же линии?
На новой линии ??
НИКАКОГО БРЕСТА ВСЕ ???

Правильные ответы 1) и 3). 1) только если мы абсолютно должны, как в tryили switchзаявлениях. Нам не платят за количество строк кода, поэтому мы не добавляем бессмысленные строки только с открывающими скобками. И если мы можем полностью опустить скобки, хорошо. Вот отличное утверждение, если вы спросите меня:

if (something)
    outer:
    for (String thing : list)
        inner:
        do
            if (somethingElse)
                break inner;
            else
                continue outer;
        while (true);

Это должно научить их младших не трогать мой код. Что приводит нас к:

6. Ярлыки

С ними все в порядке. Я вырвусь из своих петель в любое время, когда захочу. Не говорите мне, что лейблы — это способ сказать GOTO в Java , они гораздо более сложные. (Кроме того, gotoэто зарезервированное слово в Java, и это фактическая инструкция байт-кода). Так что я с радостью прыгну вперед:

label: {
  // do stuff
  if (check) break label;
  // do more stuff
}

Или мой прыжок назад:

label: do {
  // do stuff
  if (check) continue label;
  // do more stuff
  break label;
} while(true);

(посмотрите, как в приведенном выше примере для отступа использовались два пробела вместо четырех (или табуляции). Еще одна отличная тема для дальнейшего обсуждения)

7. Чувствительность к регистру

К сожалению, у нас, Java-людей, не может быть никаких очень-очень-очень- очень важных дискуссий о корпусе, потому что, к сожалению, Java чувствителен к регистру языков.

Но возьмите SQL (или PL / SQL, T-SQL для этого). При написании SQL мы можем иметь потрясающие дискуссии о том, должны ли мы

-- Upper case it all
SELECT TAB.COL1, TABLE.COL2 FROM TAB
 
-- Upper case keywords, lower case identifiers
SELECT tab.col1, tab.col2 FROM tab
 
-- Lower case keywords, upper case identifiers
select TAB.COL1, TAB.COL2 from TAB
 
-- Lower case it all
select tab.col1, tab.col2 from tab
 
-- Add some PascalCase (awesome SQL Server!)
SELECT Tab.Col1, Tab.Col2 FROM Tab
 
-- Mix case-sensitivity with case-insensitivity
-- (Protip to piss off your coworkers: Name your
-- table "FROM" or "INTO" and let them figure out
-- how to query that table)
SELECT TAB."COL1", TAB."col2" FROM "FROM"
 
-- PascalCase keywords (wow, MS Access)
Select TAB.COL1, TAB.COL2 From TAB

Теперь это действительно невероятно интересно. А поскольку это так интересно и важно, вы можете только представить количество интересных обсуждений, которые мы провели в группе пользователей jOOQ, например, о том, как лучше всего генерировать метаданные из базы данных. С помощью jOOQ мы обещаем, что вы можете расширить эти заманчивые обсуждения из области SQL в область Java , переопределив поведение генератора кода по умолчанию:

Должны ли классы быть PascalCased, а литералы — UPPER_CASED?
Должно ли все быть PascalCased и camelCased как в Java?
Должно ли все быть сгенерировано как указано в базе данных?

Бесконечные интересные дискуссии!

У нас так много вариантов использования SQL, что приводит нас к

8. SQL форматирование

В отличие от языков общего назначения в стиле C, таких как C, Java, Scala, C # или даже с ключевыми словами, Delphi, Pascal, Ada, SQL имеет еще одно замечательное основание для многочисленных дискуссий. Он не только насыщен ключевыми словами, но также имеет очень сложный и крайне нерегулярный синтаксис. Так что нам повезло, что мы смогли выбрать (после долгих обсуждений и расчетов) между:

-- All on one line. Don't tell me about print margins,
-- Or I'll telefax you my SQL!
SELECT table1.col1, table1.col2 FROM table1 JOIN table2 ON table1.id = table2.id WHERE id IN (SELECT x FROM other_table)
 
-- "Main" keywords on new line
SELECT table1.col1, table1.col2
FROM table1 JOIN table2 ON table1.id = table2.id
WHERE id IN (SELECT x FROM other_table)
 
-- (almost) all keywords on new line
SELECT table1.col1, table1.col2
FROM table1
JOIN table2
ON table1.id = table2.id
WHERE id IN (SELECT x FROM other_table)
 
-- "Main" keywords on new line, others indented
SELECT table1.col1, table1.col2
FROM table1
  JOIN table2
  ON table1.id = table2.id
WHERE id IN (
  SELECT x
  FROM other_table
)
 
-- "Main" keywords on new line, others heavily indented
SELECT table1.col1, table1.col2
FROM table1 JOIN table2
              ON table1.id = table2.id
WHERE id IN (SELECT x
             FROM other_table)
 
-- Doge formatting
SUCH table1.col1,
                 table1.col2
    MUCH table1
JOIN table2 WOW table1.id
            = table2.id
WHICH              id IN
   (SUCH x
 
WOW other_table
            )

Doge SQL Formatting

И так далее. Теперь любой руководитель проекта должен зарезервировать не менее 10 человеко-недель в каждом проекте для согласования правил форматирования SQL.

9. emacs против vim против vi против Eclipse против IntelliJ против Netbeans

Можем ли мы, пожалуйста, провести еще одну очень интересную дискуссию о том, какой из них лучше? Пожалуйста!

10. Последнее, но не менее: Вьетнам информатики

Если вы не слышали об этом очень интересном обсуждении, есть люди, которые считают, что ORM устарели , потому что ORM работают не так, как обещали. И они абсолютно правы. И самое главное, все остальные тоже совершенно правы .

Почему это здорово? Потому что это означает, что мы можем обсудить это. Бесконечно!

Хотя все продолжают говорить о таких ОРМ, никого не волнует, что Гэвин Кинг (создатель Hibernate ) сказал с самого начала:

Гэвин Кинг в Hibernate — никто не слушал беднягу

Почему мы должны заботиться о его мнении? У нас есть собственное, намного превосходящее мнение! Давайте еще поговорим о том, почему ОРМ злые!

Вывод

Самое замечательное в таких социальных сетях, как Reddit, Hackernews и других, заключается в том, что мы, наконец, можем потратить целый день на обсуждение действительно действительно интересных тем, вместо того, чтобы исправлять их скучные ошибки, которые наш босс хочет, чтобы мы исправили. В конце концов, это ВАЖНО.

Или, как сказал бы Рэндалл Манро: «Дежурные звонки!»

дальнейшее чтение

Если вы все в восторге и готовы к обсуждению, пожалуйста, подумайте также о прочтении этих очень интересных и проницательных статей о том, как лучше всего форматировать и стилизовать код:

Или добавьте свой собственный. Есть еще много важных писательских работ!

Топ 10 очень, очень очень важные темы для обсуждения

Топ 10 очень, очень очень важные темы для обсуждения

0. Пробелы

1. Haskell лучше, чем [ваш язык]?

2. Новые строки и комментарии

3. Конец DBA

4. JSON полностью лучше XML

5. фигурные скобки

6. Ярлыки

7. Чувствительность к регистру

8. SQL форматирование

9. emacs против vim против vi против Eclipse против IntelliJ против Netbeans

10. Последнее, но не менее: Вьетнам информатики

Вывод

дальнейшее чтение

Категории

Последние статьи

Рефакторинг Hudson God Class

Альтернативы синтаксиса Java лямбда

Morphia и MongoDB: развивающиеся структуры документов

OpenShift Express: развертывание приложения Java EE (с поддержкой AS7)

Интеграция jqGrid, REST, AJAX и Spring MVC