再也没有了当年的激情，去写出优雅和兼容并存的代码

优雅是自己的事。。。。一个人觉得优雅，别人接手的时候可能会觉得这写的什么玩意儿。还有三年前觉得优雅，三年后感觉一坨屎的情况。
最佳实践才是王道
如果做不到最佳实践，那就还是那句话，又不是不能用.jpg

@locoz 可能是领域关系，我让 GPT3.5 写比较复杂的后端代码，会出现不少问题。如果是前端，应该没问题。

追求优雅是个误区，应该追求语义化、别人看得懂，简单的代码，追求容易维护扩展的系统设计。
代码写的再好，想挑毛病还能挑不出毛病？要挑毛病，linus 来了都要给我叫爹

@nikola11
@tool2d 冗余的意思是，例如把用户的昵称带上了，
问前面设计的人说，昵称不能改
现在产品说要加改的功能，改个昵称，至少要改 7 张表，这也算是正常场景？

冗余数据去解决查询问题，我认为不合理，冗余 在我看来就没有优点

@QlanQ 老旧代码没人想去维护，是 7 张表最主要的原因。

twitter 上老外有一定的时间可以给你整理旧代码，国内很少见，项目周期很紧张。大家都只加新代码，不删旧代码。

当项目换了几波人接手后，加一个新功能别说 7 张表，改动 10 张表我都不会觉得奇怪。

第一行不是严格模式,没有类型,代码冗余 实现方式太 low
比如第一个直接一行就够 ltrim(ltrim('0x1234','0x'),'0X')
多次使用的魔数没有定义为常量
重复实现内置函数,dechex, hexdec
变量命名不符合语义,比如$value,跟写$a 没啥区别
差评

@tool2d #42 事实上结果恰恰相反，让 AI 写前端很难，因为前端太抽象了，描述做不到那么准确，反而是写纯后端类的代码很好写。你这其实单纯是 GPT3.5 的问题而已，不仅可注意的 Token 数量少，本身逻辑能力也弱，换 GPT4 就解决了。

渐渐对写代码失去兴趣，也慢慢不知道自己要做什么。

@buffzty 写的 low 不 low 就随你说了，但是不像你挑别人毛病，自己给出的方案还是 bug ，你用 dechex 把 1000000000000000000000 转化成十六进制给我看看

@tool2d 去年新开的坑，我觉得这样设计，实在是有问题
如果说以前 通过冗余是为了避免过度链表
但是一个新项目还这样设计，我觉得就是设计上的问题

@QlanQ 不管新旧项目，都离不开发展历史问题，只能说你遇到的项目还不够多吧，有时候某个模块当初的开发者设计的挺好的，但是顶不住需求变更。比如常见的 用户表、用户信息扩展表、供应商用户表、地推员 等等等等，开始是挺独立的业务，但是后来某天产品要求做个列表，产品为了方便，这个列表的展示信息，居然横跨 7 个表，你能选择的无非就是上面讨论的两个方案，要么冗余出来，要么查多表

每个人的优雅方式不一样， 当一个项目经过 N 个人的手之后， 你会发现跟荒地上的 杂草一样。
所以。。。能用 if else 解决的 就不要优雅的用设计模式。

这个帖子，贴了代码之后就很容易跑偏，本来是随想贴，变成了指点贴

@fyxtc 我也很无奈，现在的我，也不是想贴段代码比个高低，争个第一了，没有意义了啊，哎

先把汉字打对再说，是“令你感到骄傲”。
另外有本书叫《重构》，有个工具叫 chatgpt

@brader 项目也做了不少，接手的也很多，没见过，明知会改，还要用来冗余的，而且只是为了查询所以加了冗余的，
丝毫不考虑 修改的时候怎么处理么？

那么多数据冗余在一张表里面，查询效率也不会高吧，

两种方案，实在是看不出来 冗余的方案，有什么优势或者说好处

吃饭的项目不要想优雅，能跑就行。

自己业余兴趣搞的项目，最好还是追求下。

@NessajCN

@buffzty trim 系类函数的第二个参数是按照字符进行处理的，你这个还可以简化成 ltrim('0x1234', '0xX')，但是这样是会存在问题的。

比如 ltrim('0x0f', '0xX')，的输出结果将会是 f 而不是预期 0f

@buffzty 不过可以改为：ltrim(ltrim('0x0f','0'),'xX')