Código conciso: claro e breve

Tomemos como exemplo o ato de salvar um usuário no único banco de dados acessado por uma aplicação:

Ele é claro, e chega a ser até mesmo redundante uma vez que "tipifica" o nome do método ao repetir a palavra database. Já o código a seguir mantem a clareza relativa a responsabilidade citada, além de ser sucinto:

Em uma outra situação, o mesmo código acima pode ser implementado executando outras tarefas, como inserindo outros objetos relativos a um usuário:

Agora o código anterior, continua sucinto mas já não é mais tão claro:

Ele não diz que faz o que realmente fará. A busca pelo código curto introduziu a possibilidade de engano daquele que vai ler, pior ainda, o nome do método e a maneira de implementá-lo levam ao erro: ele não é conciso, ele é somente breve.

Por isso alguns usos excessivos de técnicas avançadas, como AOP ou mesmo reflection, precisam de muito cuidado. Remotabilidade transparente, EJBs, JPA, ActiveResource e quaisquer outras bibliotecas que trabalham um serviço de maneira a ocultá-lo podem gerar problemas caso o usuário não tenha um certo conhecimento do efeito de suas chamadas. É o caso do excesso de invocações remotas ou de queries sqls, que os frameworks já citados podem trazer sem um conhecimento mais profundo..

Concisão não significa texto curto. Um dos grandes desafios de um autor é ser conciso, para não cansar seus leitores, mantendo a clareza de seu texto. Algumas linguagens ou até mesmo bibliotecas podem acelerar ou desacelerar o processo de falar algo com poucas palavras, o que não significa necessariamente o código mais fácil de entender e, consequentemente, de manter a longo prazo.

Escrever pouco - a métrica de linhas de código - traz o menor código, mas não necessariamente o mais claro ou melhor. No exemplo a seguir, o cliente está sendo somente salvo ou algo mais está sendo feito e a "pseudo-concisão" está nos enganando?