From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 31A2729B7A for ; Fri, 17 Aug 2018 05:20:10 -0400 (EDT) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TcA4zog2QWts for ; Fri, 17 Aug 2018 05:20:10 -0400 (EDT) Received: from smtp45.i.mail.ru (smtp45.i.mail.ru [94.100.177.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTPS id A3E9429B75 for ; Fri, 17 Aug 2018 05:20:09 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: [tarantool-patches] Re: [PATCH 2/2] sql: remove GLOB from Tarantool From: "n.pettik" In-Reply-To: <193c5885-f295-9753-573e-aa4ae1bd7e89@tarantool.org> Date: Fri, 17 Aug 2018 12:20:00 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4607dc428909e96915e9f0984a7733a0890a3185.1534436836.git.n.tatunov@tarantool.org> <76466086-2a5f-8f12-cbc3-4ddf26e30fd9@tarantool.org> <4137B8ED-FBEF-4B41-A84F-83AB8F75D0D6@tarantool.org> <193c5885-f295-9753-573e-aa4ae1bd7e89@tarantool.org> Sender: tarantool-patches-bounce@freelists.org Errors-to: tarantool-patches-bounce@freelists.org Reply-To: tarantool-patches@freelists.org List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: tarantool-patches List-subscribe: List-owner: List-post: List-archive: To: tarantool-patches@freelists.org Cc: Alexander Turenko , Alex Khatskevich , "N. Tatunov" > On 17 Aug 2018, at 12:01, Alex Khatskevich = wrote: >=20 > On 17.08.2018 11:49, n.pettik wrote: >>> On 17 Aug 2018, at 11:25, Alex Khatskevich = wrote: >>>=20 >>> Do not split error messages at the middle of a sentence. It makes = errors ungreppable. >>> Make it <80 somehow different. >> I guess this is extremely specific nitpicking: look at = src/box/alter.cc: >> through the code there are a lot of breaks of error messages like: >>=20 >> alter.c : 405 >>=20 >> tnt_raise(ClientError, errcode, tt_cstr(space_name, name_len), >> tt_sprintf("field %d has conflicting nullability and " >> "nullable action properties", fieldno + >> TUPLE_INDEX_BASE)); >>=20 >> alter.cc : 524 >>=20 >> if (exact_field_count !=3D 0 && >> exact_field_count < field_count) { >> tnt_raise(ClientError, errcode, tt_cstr(name, name_len), >> "exact_field_count must be either 0 or >=3D "\ >> "formatted field count=E2=80=9D); >>=20 >> etc > That is not a good example of code. Okay, then look at key_def.c and other source files. I can=E2=80=99t = find example of breaking 80 chars border with error string message. Thus, I guess this rule is = unlikely to be supported within our codestyle. > If possible, error message should not be broken at the middle. > In my opinion, even if it is not possible, it should better be > 80. >=20 > Linus is for this = https://www.kernel.org/doc/html/v4.10/process/coding-style.html