duangsuse::Echo
718 subscribers
4.26K photos
130 videos
583 files
6.48K links
import this:
美而不丑、明而不暗、短而不凡、长而不乱,扁平不宽,读而后码,行之天下,勿托地上天国。
异常勿吞,难过勿过,叹一真理。效率是很重要,盲目最是低效。
简明是可靠的先验,不是可靠的祭品。
知其变,守其恒,为天下式;穷其变,知不穷,得地上势。知变守恒却穷变知新,我认真理,我不认真。

技术相干订阅~
另外有 throws 闲杂频道 @dsuset
转载频道 @dsusep
极小可能会有批评zf的消息 如有不适可退出
suse小站(面向运气编程): https://WOJS.org/#/
Download Telegram
Forwarded from Hung-I Wang
那有没有 Allow writing class types as {a: int, b: int} (
Forwarded from Luke 🦀
这个还有点 row polymorphism 的感觉...
Forwarded from dnaugsuz
https://github.com/duangsuse-valid-projects/Share/blob/master/Others/fill_template.py 我也是2空格。 不用 tab 是觉得语义不好,而且很多默认/强制4空格渲染的;不用4空格是嫌浪费行长,无意义
Forwarded from dnaugsuz
那个…… 提几个建议
1.不要再起 n:str 了,红姐也有这种习惯,换 s:str 或 name:str 吧,激进一点也可以叫 sKey
同理激进命名也可以前置 mainf 的 f, 并精确为 fpOrigin
2.retrun tuple 的时候可以加括号;局部赋值 unpack 时也可以
3.Entry.__lt__(other:str) 序运算符解析了其上 value ,也可以在 ctor 里缓存下
4.s.split(' ',limit=1) 可以抽提下
5.我知道 write_main 里面你 .value[:-1] 是 .rstrip('\n') 的意思+必然存在断言,但即便你能断言,原本的逻辑最好还是注释下,编程中这类“优化”还挺多的,得注意
Forwarded from v m
匈牙利名字不是很早就不推荐使用了吗
Forwarded from dnaugsuz
可是这种命名法有利于简化复杂计算的编写

而且我习惯的命名规范没有匈牙利那么冗,不会包含作用域信息也没严格按照语言内的类型,更像物理命名法

Python 习惯的人就是最常写那种用完扔的脚本的,按 Java/C# 玩家的说法就是“开发IDE都有点浪费”,就这他们推荐的你还能完全遵从……
dnaugsuz
那个…… 提几个建议 1.不要再起 n:str 了,红姐也有这种习惯,换 s:str 或 name:str 吧,激进一点也可以叫 sKey 同理激进命名也可以前置 mainf 的 f, 并精确为 fpOrigin 2.retrun tuple 的时候可以加括号;局部赋值 unpack 时也可以 3.Entry.__lt__(other:str) 序运算符解析了其上 value ,也可以在 ctor 里缓存下 4.s.split(' ',limit=1) 可以抽提下 5.我知道 write_main 里面你…
#statement #dev #pl 补充一句,我用的不是匈牙利命名法(这个名字本身怎么那么狭隘……匈牙利人常用么)

匈牙利命名法是 property(常量/类属性/可变量)+简写type+描述

我的命名法是在长期重构和编程中自创的,大小写分词(camel/snake)基于 Kotlin 的规范,但在特定子程序(涉及物理量/同名不同形式量 比较多的)会有更清晰的模式,甚至可以替代类型声名,我管它叫『物理命名法』

匈牙利命名法重视类型前缀,物理命名法却重视类型本身——因为很多作用域范围内同类型只会有一个值,或一个 1:N 相关值出现,所以除了类型简写,描述往往省略

它有4种模式:
单/多个量: x, xs, xz(Iterator)
嵌套级简写: evt=ev.target, ek=e.key
量化: nX=xs.size, kX=xs.keyOf(x)
时序/编号: v, v1/oldV; t0, t1

类型简写:
i,j,n,m: Int
w,h,l: Int|Double
s: String
c: Char
op: Function
p: (T) -> Boolean
ex: Exception
d: Map
e: Map.Entry|Element
k: K
x,v: T
f: File; fp: FilePath
ev: Event
Forwarded from dnaugsuz
关键是现在各领域交错,程序猿不可能“一招鲜,吃遍天”啊,总是要多会几门,JVM 方便企业应用和服务工具;Py 方便信息批处理;C/C++ 方便写玩具和os接口

所谓编程规范、命名规范,就是一个 formatter, transpiler 翻译下就符合了的东西,只有机器味没有人情味,比 generator, await/async 这样的东西无意味多了,毕竟,语言背后藏着的只是抛开后端接口,所有语言通用的算法和业务逻辑啊

以这种想法编程,你就不会在意代码所用那门语言的编程规范了,因为 camelCase, snake_case, ALLUPPER 这些分词方式,根本就是机器都能转化的工作呢
唉,不知道是不是 snake_case 更适合人类,我中国人可能没有什么感觉

但是世界上其实也有不少出于好的目的做的事,最后却事与愿违的例子,但愿不会有这样

不过我是真觉得 #Kotlin 的 fun 比 #Rust 的 fn, #Go 的 func, #Python 的 def 好看,总感觉就这一词的选择,不谈 val/var 的对仗,已高下立判。

或许是因为那个“乐趣”真的很吸引眼球吧,对子程序的利用,本身就是非常有意思的事情
Forwarded from GNU/Akari
* pep8 的存在就是为了降低人类阅读的成本。
* 我并没有否认适当违反规则的重要性,这点 pep8 里也有讲。但是如果一点都不遵守的话 pep8 就没有存在的意义了。
Forwarded from dnaugsuz
别提代码风格,看看解决了什么类型的问题吧
Forwarded from dnaugsuz
要命。有什么好处呢?总是赢,不肯选择和接受别人的观点
我要是一直这样,走不到今天
Forwarded from dnaugsuz
一句话不说是最好的,闷声发大财
人们总是选择相信他们相信的东西,排斥不相信的东西,连看都不屑

即便三年前的我也知道要想改变一个东西,你得先融入它,证明自己懂它,才有资格批评它;
现在我看见别人对他们讨厌的东西,选择屏蔽掉,视若未见。
Forwarded from dnaugsuz
很多人在意的根本不是真理,他们并不希望让自己拥有更好看且可移植、定义式、高性能的编程思想/代码风格,只是简单地不愿让自己一直相信的东西被破坏罢了,就像中国一些只想着怎么讨好上级,不认真对待问题的人一样。

可惜不破不立啊,不探索怎么知道怎么做、合不合适
刚刚与我谈解释器等语言工具里不方便用全名的群友,是否知道我目前就正在用 Python 写一个支持宏展开的项目生成工具呢…… 😒
我举的例子也是一个完整、支持调用局部作用域、 Kotlin Multiplatform 的解释器,虽然还没有惰性求值调用这样的功能,控制流都实现了,他怎么不结合评价下呢
闷声发大财?
Anonymous Poll
78%
🐸吼啊
22%
下次看见你还是应该说
duangsuse::Echo
闷声发大财?
下次看见我也这样回他们:“你说的很对。”

我连阴阳怪气都懒得弄,因为,受损失的并不是我,就像我一点也不觉得 NMSL, CNMB 这样的词很好气一样,这些纯情绪的表达,其它群友能理解吗?有价值吗?

很可惜,他们不是我,或许在他们的生活里,编程没有其它的一些东西重要吧。
为什么中国人总爱问别人“你懂不懂” “你知不知道”,不爱说“我能给你讲下吗” “是我讲得不清楚吗” “这个没什么,只不过是这样而已”
This media is not supported in your browser
VIEW IN TELEGRAM